Transaction coordinator for digital certificate validation and other services

ABSTRACT

Systems and methods for facilitating electronic commerce by securely providing certificate-related and other services including certificate validation and warranty. In a preferred embodiment, these services are provided within the context of a four-corner trust model. The four-corner model comprises a buyer, or subscribing customer, and a seller, or relying customer, who engage in an on-line transaction. The buyer is a customer of a first financial institution, or issuing participant. The issuing participant operates a certificate authority and issues the buyer a hardware token including a private key and a digital certificate signed by the issuing participant. The seller is a customer of a second financial institution, or relying participant. The relying participant operates a certificate authority and issues the seller a hardware token including a private key and a digital certificate signed by the relying participant. The system also includes a root certificate authority that operates a certificate authority that issues digital certificates to the issuing and relying participants. At the time of a transaction, the buyer creates a hash of the transaction data, signs the hash, and transmits the transaction data, the signature, and its digital certificate to the seller. The seller may then request system services via a connection with its financial institution, the relying participant. The system services may include a certificate status check service and a warranty service. The certificate status check service allows the relying customer to validate the subscribing customer&#39;s certificate. The warranty service allows the relying customer to receive a collateral-backed warranty that the subscribing customer&#39;s certificate is valid. Each participant and the root entity is provided with a transaction coordinator for combining services and operations into a single transaction having the qualities of atomicity, consistency, isolation, and durability. The transaction coordinator provides a single consistent interface for certificate-status messages and requests, as well as messages and requests relating to other services.

RELATED APPLICATIONS

This application is a continuation of and claims priority from U.S.patent application Ser. No. 09/950,440 filed Sep. 10, 2001 entitledSystem and Method for Providing Certificate Validation and OtherServices, which application claims priority from U.S. provisional patentapplication Ser. No. 60/231,319, filed Sep. 8, 2000, entitledTransaction Coordinator Certificate Status Check (CSC) ProtocolDefinition, Transaction Coordinator Messaging Protocol Definition, andTransaction Coordinator Requirements. Said two prior patent applicationsare hereby incorporated by reference in their entireties into thepresent patent application. Application Ser. No. 09/950,440 is also acontinuation of U.S. patent application Ser. No. 09/657,605, filed Sep.8, 2000, entitled System and Method for Providing Certificate Validationand Other Services, which claimed priority to U.S. provisional patentapplication 60/153,726, filed Sep. 13, 1999, entitled TransactionCoordinator for Certificate Status Checking and Other Services; U.S.provisional patent application 60/153,724, filed Sep. 13, 1999, entitledTransaction Coordinator Requirements and High Level Design; and U.S.provisional patent application Ser. No. 60/153,203, filed Sep. 10, 1999,entitled System and Process for Certification in Electronic Commerce.All of the prior patent applications mentioned in this paragraph arehereby incorporated by reference in their entireties into the presentpatent application.

FIELD OF THE INVENTION

This invention relates generally to the field of facilitating electroniccommerce by providing services via a public key infrastructure.

BACKGROUND OF THE INVENTION

The world of electronic commerce has created new challenges toestablishing relationships between contracting parties. One of thosechallenges springs from the fact that the parties to the transactioncannot see or hear each other, and cannot otherwise easily confirm eachother's identity and authority to act.

One remedy for this problem is to provide each contracting party with aprivate key for signing transmitted messages. The signing party makesavailable an associated public key that decrypts messages signed withthe party's private key, and thus enables a receiving party to confirmthe identity of the sender.

But the sender's public key may not be known a priori to the recipient.In that event, the sender may transmit with its signed message a digitalcertificate issued by a certificate authority. The certificate is itselfa signed electronic document (signed with the private key of thecertificate authority) certifying that a particular public key is thepublic key of the sender. In some cases, the recipient may be unfamiliarwith the public key of the certificate authority or may not know whetherthe certificate is still valid. In that event, the recipient may wish tocheck the authenticity and validity of the certificate with an entitythat it trusts. One known protocol for checking certificate status isthe on-line certificate status protocol (OCSP).

SUMMARY OF THE INVENTION

Systems and methods for facilitating electronic commerce by securelyproviding certificate-related and other services including certificatevalidation and warranty. In a preferred embodiment, these services areprovided within the context of a four-corner trust model. Thefour-corner model comprises a buyer, referred to as the subscribingcustomer, and a seller, referred to as the relying customer, who engagein an on-line transaction. The buyer is a customer of a first financialinstitution, referred to as an issuing participant. The issuingparticipant acts as a certificate authority for the buyer and issues theseller a hardware token including a private key and a digitalcertificate signed by the issuing participant. The seller is a customerof a second financial institution, referred to as the relyingparticipant. The relying participant acts as a certificate authority forthe seller and issues the seller a hardware token including a privatekey and a digital certificate signed by the relying participant. Thesystem also includes a root certificate authority that issues digitalcertificates to the issuing and relying participants.

At the time of a transaction, the buyer creates a hash of thetransaction data, signs the hash, and transmits the transaction data,the signature, and its digital certificate to the seller. The seller maythen request system services via a connection with its financialinstitution, the relying participant.

In a preferred embodiment, these system services may include acertificate status check service and a warranty service. The certificatestatus check service allows the relying customer to validate thesubscribing customer's certificate. The warranty service allows therelying customer to receive a collateral-backed warranty that thesubscribing customer's certificate is valid. Detailed message flows forproviding these services are provided in the detailed description.

In a preferred embodiment, each participant and the root entity isprovided with a transaction coordinator for combining services andoperations into a single transaction having the qualities of atomicity,consistency, isolation, and durability. The transaction coordinatorprovides a single consistent interface for certificate-status messagesand requests, as well as messages and requests relating to otherservices. As a result, the present invention provides the necessaryflexibility to permit centralized and consistent capture oftransactional information relating to a plurality of offered servicesfor audit and non-repudiation purposes. In addition, the presentinvention facilitates the integration of additional services andprovision of those services to customers.

The disclosed transaction coordinator provides a single interface tofacilitate electronic communications amongst banks or other financialinstitutions or between banks or other financial institutions and theircustomers. The transaction coordinator also provides a single entrypoint for customers to obtain certificate-check services and providesthe flexibility to add new business application services, such aswarranty service, payment guarantee service, or certified mail service,while still providing a single entry point for these additionalservices. It is preferably designed to be easily extended to supportadditional services as they are created.

The disclosed transaction coordinator provides parsing, flow control,and error handling for the present messaging infrastructure and acts asa message switch to route message components to an appropriate systemservice (e.g., to an OCSP responder, warranty engine, etc.). Inaddition, it collates responses from these services into a consolidatedresponse and dispatches the responses to requesting clients.

The disclosed transaction coordinator also records billing data for thecertificate check service or other services in a centralized generalfashion. Because all of the banks and other financial institutions havetheir own requirements for billing, the billing data can be extractedand modified to an individual financial institution's needs by writingsimple extraction functions.

The disclosed transaction coordinator also allows banks or otherfinancial institutions to cross-charge each other for different types oftransactions as needed. Further, the disclosed transaction coordinatorallows for the integration of commercial off-the-shelf softwareapplications and provides a single electronic signing service toelectronically sign and verify documents.

In addition, the disclosed transaction coordinator isolates all coreservices, thereby promoting reuse of components and simplifying themaintenance and enhancements of these services. The disclosedtransaction coordinator does not require changing the on-linecertification check functionality that would render it non-standard andmight result in vendor locking and implementation delays.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other objects, features, and advantages of the presentinvention will be better understood when taken in conjunction with thefollowing detailed description and accompanying drawings in which:

FIG. 1 is a block diagram of a preferred embodiment of the four-cornermodel employed by the present system;

FIG. 2 is a block diagram depicting components preferably provided atentities in the four-corner model;

FIG. 3 is a block diagram of a preferred embodiment of a transactioncoordinator;

FIG. 4 is a composite block/flow diagram that demonstrates certainaspects of transaction coordinator operation in a preferred embodiment;

FIG. 5 is a composite block/flow diagram depicting preferred operationof the signing component of a transaction coordinator;

FIG. 6 is a composite block/flow diagram demonstrating a preferredembodiment of the steps performed by a transaction coordinator inperforming a certificate status check;

FIG. 7A is a composite block/flow diagram illustrating a preferredembodiment of the transaction flow for validating a certificate;

FIG. 7B is a portion of the composite block/flow diagram illustrating apreferred embodiment of the Transaction flow for validating acertificate of FIG. 7A;

FIG. 8A is a composite block/flow diagram illustrating the transactionflow for one preferred embodiment of a warranty service;

FIG. 8B is a portion of the composite block/flow diagram illustratingthe transaction flow for the preferred embodiment of a warranty serviceof FIG. 8A;

FIG. 9 is a composite block/flow diagram of a preferred embodiment ofserver-side authentication;

FIG. 10 is a composite block/flow diagram of a preferred embodiment ofclient-side authentication;

FIG. 11 is a composite block/flow diagram illustrating a preferredmessage authentication process;

FIG. 12 is a composite block/flow diagram of a preferred embodiment ofthe security-relevant flows associated with components of a transactioncoordinator;

FIG. 13 is a composite block/flow diagram that depicts the (estimated)sizes of messages that are passed between system entities in a preferredembodiment;

FIG. 14 is a composite block/flow diagram that depicts the transactionflows for an OCSP-proxy centric embodiment of the present system.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present disclosure relates to a system that allows financialinstitutions to securely perform electronic certificate status checksand other services for their customers. In a preferred embodiment, thedisclosed system employs a four-corner trust model to provide theseservices. A preferred embodiment of the four-corner model employed bythe present system is shown in FIG. 1.

As shown in FIG. 1, the four-corner model comprises a first institution102 and a second institution 104. First institution 102 is referred toas the “issuing participant” because it is a participant in the presentsystem and issues smart cards to its customers, as described below.Second institution 104 is referred to as the “relying participant”because it is a participant in the present system and its customers relyon representations made by issuing participant 102 and issuingparticipant 102's customers, as described below. Participants 102, 104are typically banks or other financial institutions.

Also shown in FIG. 1 are a first customer 106, and a second customer108. First customer 106 and second customer 108 are preferably customersof issuing participant 102 and relying participant 104, respectively.First customer 106 is referred to as the “subscribing customer” becauseit subscribes to services provided by issuing participant 102. Secondcustomer 108 is referred to as the “relying customer” because it relieson representations made by both issuing participant 102 and subscribingcustomer 106.

Also shown in FIG. 1 is a root entity 110. Root entity 110 is typicallyan organization that establishes and enforces a common set of operatingrules for facilitating electronic commerce and electroniccommunications. Root entity 110 may be owned jointly by a plurality ofbanks and/or other financial institutions that have agreed to adhere tothese operating rules. One exemplary embodiment of such a root entity isdescribed in copending application Ser. No. 09/502,450, filed Feb. 11,2000, entitled System and Method for Certification-Related and OtherServices, which is hereby incorporated by reference.

FIG. 2 is a block diagram depicting components preferably provided atentities in the four-corner model. As shown in FIG. 2, participants 102,104 and root entity 110 are each provided with a transaction coordinator202 that serves as a gateway for transmitting and receiving allinter-entity messages related to services provided by the presentsystem. As described in more detail below, transaction coordinators 202provide a single interface to issuing participant 102's and relyingparticipant 104's on-line services, and implement safeguards necessaryto ensure secure electronic communications between transactioncoordinators 202 and other entities in the four-corner model. Onepreferred embodiment of a transaction coordinator 202 is described belowin connection with FIGS. 3-6.

Participants 102, 104 and root entity 110 are each further preferablyprovided with an OCSP responder 204 and hardware security module (HSM)206. Exemplary requirements for an OCSP responder 204 are describedbelow. HSM 206 is adapted to sign messages and verify signatures onmessages, as described below, in connection with FIG. 6.

In addition, each participant 102, 104 and root entity 110 is furtherpreferably provided with a billing data database 208 (connected to abank billing application 210 in the case of participants 102, 104), araw transaction log, 212, a customer data database 214, a risk manager216 (connected to customer data database 214), and a second hardwaresecurity module 218, each of which is connected to transactioncoordinator 202.

As further shown in FIG. 2, relying customer 108 is preferably providedwith a Web server 220 that is adapted to receive and transmitinformation via the Internet. Relying customer 108 is further preferablyprovided with a bank interface 222 for communicating with relyingparticipant 104, as described in more detail below. One preferredembodiment of bank interface 222 (as well as additional componentspreferably provided at the relying customer) is described in copendingU.S. patent application Ser. No. 09/657,604, filed Sep. 8, 2000,entitled System and Method for Facilitating Access By Sellers toCertificate-Related and Other Services, which is hereby incorporated byreference. Relying customer 108 is preferably further provided with ahardware security module 230 for signing and verifying system messages.

As further shown in FIG. 2, subscribing customer 106 is preferablyprovided with a Web browser 224 for browsing the Internet and a smartcard 226 (and associated reader) for signing digital messages, asdescribed below.

In a preferred embodiment, each system entity is provided with twodigital certificates (and corresponding private keys) to facilitateauthentication: An identity certificate (also referred to, in somecases, as a warranty certificate) and a utility certificate. Inaddition, in a preferred embodiment, each transaction coordinator 202 ispreferably provided with its own identity certificate and utilitycertificate and associated private keys.

The identity private key is used to produce digital signatures that arerequired by root entity 110 as evidence of an entity's contractualcommitment to the contents of an electronic transaction. A certificatechain is needed to support operations using this key. The status of theidentity certificate may be obtained by authorized entities, asdescribed below.

The utility private key is used to produce digital signatures that allowadditional transactional security. Typically, utility certificates areused to support secure socket layer sessions, to sign S/MIME messages,and for other utility applications. A certificate chain is also neededto support operations using the utility key. The status of the utilitycertificate, however, may not be available to a requestor. Throughoutthis document, the term “certificate” refers to an identity certificateunless otherwise stated.

In a preferred embodiment, subscribing customer 106's digitalcertificates and associated private keys are provided to it by issuingparticipant 102. Issuing participant 102 preferably issues smart cardsor other suitable instruments to subscribing customer 106 that includeat least the private key associated with the subscribing customer'sidentity certificate. If desired, the smart card may also include thesubscribing customer's identity certificate. Preferred specificationsfor the smart card, its manufacture, and contents are described in U.S.provisional patent application Ser. No. 60/224,994, filed Aug. 14, 2000,entitled Signing Interface Requirements, Smart Card ComplianceRequirements, Warranty Service Functional Requirements, and AdditionalDisclosure, which is hereby incorporated by reference.

FIG. 3 is a block diagram of a preferred embodiment of a transactioncoordinator 202. As shown in FIG. 3, transaction coordinator 202preferably comprises an interface 302 comprising two components: a TCrequest manager 304 and a transport services component 306. Interface302 passes communications to and from a plurality of service modules 308and core components 310. Service modules 308 preferably include acertificate status check module 312, warranty service module 314, apayment guarantee module 316, and may comprise other service modules 318for providing additional services. Core components 310 preferablyinclude a logging component 320, a billing component 322, and a signingcomponent 324.

Transport services component 306 provides a single entry point into thetransaction coordinator and acts as an isolation layer between arequestor and the transaction coordinator's service modules and corecomponents. Request manager 304 receives service requests from transportservices component 306 and forwards them to appropriate service modulesand/or core components, as described in more detail below.

The function of certificate status check service 312 is to validate thecertificates of entities within system 200 of FIG. 2. The function ofwarranty service 314 is to guarantee the identity of an entity thatsigns an electronic communication relating to a particular businesstransaction. In a preferred embodiment, the participant providing thewarranty, typically issuing participant 102, accepts financialresponsibility for some or all of the transaction amount if it is laterdiscovered that subscribing customer 106 did not execute a digitalsignature created with the subscribing customer's private key.

The function of payment guarantee service 316 is to further decrease therisk associated with a transaction by providing relying customer 108with immediate confirmation of subscribing customer 106's ability tofulfill a financial obligation. In addition, issuing participant 102 mayissue a payment guarantee for some or all of the transaction amount iffor some reason subscribing customer 106 fails to pay relying customer108. Payment services may also be established as described in copendingU.S. patent application Ser. No. 09/657,622, filed Sep. 8, 2000,entitled System and Method for Providing Payment Services in ElectronicCommerce, which is hereby incorporated by reference.

The function of certified mail service 318 is to support off-linetransactions. Off-line transactions occur when the receiving entity,instead of servicing the request immediately, puts the request in aprocessing queue. Typically, an acknowledgment of receipt is sent to therequestor. This scenario may preferably be implemented when thetransaction volumes are so large that it is not feasible to provideon-line responses to every request. Certified mail service 318 maypreferably be used to satisfy requests between relying customer 108 andrelying participant 104, relying participant 104 and issuing participant102, and any request made to root entity 110.

The function of logging component 320 is to log all service requests andOCSP responses in a raw transaction log 58 (see FIG. 5) fornon-repudiation and security auditing purposes.

The function of billing component 322 is to create and store atransaction billing history for messages (responses and requests)received by transaction coordinator 202. Preferred operation of thesemodules and components is further described below.

FIG. 4 is a composite block/flow diagram that demonstrates certainaspects of transaction coordinator operation in a preferred embodiment.As shown in FIG. 4, in step 4002, transport services component 306 oftransaction coordinator 202 receives a service request from anothersystem entity and sends the service request to request manager 304. Instep 4004, request manager 304 checks to see if the service requestformat is valid. If the service request format is valid, request manager304 requests information on the requestor, the billing data, and theservice request type by calling a message validation module 404. Messagevalidation module 404 calls a parser component 406 to extract therelevant information from the raw service request.

In step 4006, request manager 304 calls an authentication module 408 toauthenticate the requestor. Authentication module 408 is described inmore detail below.

In step 4008, authentication module 408 authenticates the requestor bycalling signing component 324 of transaction coordinator 202 which, inturn, calls hardware security module 218. A preferred structure andoperation for signing component 324 is described in more detail below.

In step 4010, authentication module 408 calls certificate status checkcomponent 414 that in turn calls an OCSP responder 204 to perform acertificate status check on the requestor. A preferred structure andoperation for certificate status check component 414 is described inmore detail below.

In step 4012, authentication module 408 calls a customer authorizationcheck module 418 to verify that the requestor is authorized to place theservice request. A preferred structure and operation for customerauthorization check module 418 is described in more detail below.

In step 4014, request manager 304 calls logging component 320 to log theraw service request for non-repudiation purposes. In a preferredembodiment, messages stored in the raw transaction log are stored ineither ASN.1 or XML format.

In step 4016, request manager 304 forwards any billing data necessary toappropriately bill for services provided to billing component 322 to forlogging in the billing log.

In step 4018, request manager 304 forwards the service request to aservice request router 426. In step 4020, service request router 426calls an appropriate service module 308 to fulfill the request.

In step 4022, a service response is received by service request router426 from the service module that was called in step 4020. Servicerequest router 426 forwards the service response back to request manager304 which, in turn, sends the service response to transport servicescomponents 306. Transport services component 306 forwards the serviceresponse to the entity that made the service request.

FIG. 5 is a composite block/flow diagram depicting preferred operationof signing component 324. Signing component 324 preferably provides asingle interface to different signing devices, such as smart cards andhardware security modules, and uses cryptographic processing to verifysignatures.

Turning to FIG. 5, when a request is received by signing component 324in step 5002, signing component 324 determines whether it is a requestfor signature or for verification. If the request is for verification,signing component 324 sends the request to a hardware security module218 for verification (step 5004). In step 5008, hardware security module218 responds to this request with a signature verification response tosigning component 60.

If the request is to sign a document, signing component 324 sends therequest (which should include the document to be signed) to hardwaresecurity module 218 for signature (step 5006). In step 5010, hardwaresecurity module 218 responds to this request by signing the document andreturns the signed document to signing component 324. Finally, in step5012, signing component 324 returns the signature-verification responseor signed document to the component that made the request.

FIG. 6 is a composite block/flow diagram demonstrating a preferredembodiment of the steps performed by a transaction coordinator 202 inperforming a certificate status check. In step 6002, certificate checkservice module 312 receives an unparsed certificate status check requestfrom service router 426 and forwards it to a parser component 406 thatextracts the relevant customer information (comprising the certificateto be checked) from the request. In step 6004, certificate check servicemodule 312 obtains any additional service-specific fulfillmentinformation from a customer database 606.

In step 6006, if the certificate to be checked belongs to a customer ofthe participant whose transaction coordinator 202 received the request,certificate check service module 312 hands the request off to alocal-customer handler 602. Otherwise, certificate check service module312 hands the request off to a non-local-customer handler 610.

In those cases where local-customer handler 602 handles the request, thesystem proceeds to step 6008, where local customer handler 602 sends acertificate check request to a certificate status check component 312.Certificate status check component 312 then obtains a certificate statusfor the certificate to be checked from its associated OCSP responder 204(i.e., the OCSP responder 204 belonging to the same transactioncoordinator 202 as certificate status check component 312). Flow inthese cases then continues with step 6032 below.

In contrast, in those cases where the certificate to be checked does notbelong to a customer of the participant who received the request, then,in step 6010, non-local-customer handler 610 looks up the IP address ofthe issuing participant that issued the certificate that is the subjectof the request in a static DNS table 604. Transaction coordinator 202_(RP), is preferably adapted to use the AIA extension in a certificateto identify the location of issuing participant 102. In step 6012,non-local-customer handler 610 forwards the subject certificate to anOCSP request formulation module 608. In step 6014, OCSP requestformulation module 608 formulates an OCSP request for the certificateand sends the request to signing component 324 for signature. In step6016, signing component 324 returns the signed request.

In step 6018, OCSP request formulation module 608 sends the signedrequest to the issuing participant 102 that issued the subjectcertificate. In step 6020, that issuing participant 102 returns an OCSPresponse to the request to OCSP request formulation module 608.

In step 6022, OCSP request formulation module 608 forwards the responseto non-local-customer handler 610. In step 6024, non-local-customerhandler 610 logs the raw response data to raw transaction log 212 fornon-repudiation purposes.

In step 6026, non-local-customer handler 610 sends the raw response datato parser component 406 to extract the certificates of issuingparticipant 102 and its transaction coordinator 202 _(IP) from theresponse.

In step 6028, non-local-customer handler 610 validates the issuingparticipant's transaction coordinator certificate by repeating steps6012-6024 but transmitting the OCSP request created in step 6014 to rootentity 110 rather than issuing participant 102.

Similarly, in step 6030, non-local-customer handler 610 validates theissuing participant's certificate by repeating steps 6012-6024 buttransmitting the OCSP request created in step 6014 to root entity 110rather than issuing participant 102.

In step 6032, the certification check response data received bynon-local-customer handler 610 or generated by local-customer handler602 is sent to signing component 324 which signs the response. In step6034, the signed response is sent back to certificate check servicemodule 312 which, in turn, transmits the response to service requestrouter 426.

FIG. 7 is a composite block/flow diagram illustrating a preferredembodiment of transaction flow within system 200 for validating acertificate. As shown in FIG. 7, in step 7002, subscribing customer 106creates a hash of data representing a transaction between subscribingcustomer 106 and relying customer 108 and sends the hash to smart card226 for signature. In step 7004, smart card 226 signs the data andreturns the signed data along with the certificate of subscribingcustomer 106 and issuing participant 102.

In step 7006, subscribing customer 106 sends the signed data and the twocertificates to relying customer 108. In step 7008, relying customer 108verifies the signature on the data sent by subscribing customer 106.This verification preferably includes checking the validity period ofthe received certificates. Alternatively, verification may be providedas a service to relying customer 108 by relying participant 104. Relyingcustomer 108 then creates an OSCP request containing the subscribingcustomer's and issuing participant's certificates and transmits therequest to hardware security module 230 for signature. In step 7010,hardware security module 230 returns the signed request.

In step 7012, relying customer 108 transmits the signed OCSP request torelying participant 104, along with its own certificate. In step 7014,transaction coordinator 202 _(RP) of relying participant 104 receivesthe signed OCSP request and checks customer database 214 _(RP) to makesure that the request was signed by an existing relying customer beforeprocessing the request. In a preferred embodiment, a relying participant104 does not process requests received from a customer of a differentparticipant. In step 7016, transaction coordinator 202 _(RP) stores theraw transaction data (i.e., the unparsed request, signature, andaccompanying relying customer certificate) in raw transaction log 212_(RP). In step 7018, any billing data necessary to appropriately billfor services provided is stored in billing log 208 _(RP). Alternatively,billing data may be extracted from the raw-transaction log by anoff-line process to increase system performance.

In step 7020, transaction coordinator 202 _(RP) verifies the relyingcustomer's signature on the service request using the relying customer'scertificate, the relying participant's certificate, and the root publickey. The relying participant's certificate and the root public key maypreferably be stored in hardware security module 218 _(RP).

In step 7022, transaction coordinator 202 _(RP) generates an OCSPrequest containing the relying customer's certificate, signs it, andsends it to its OSCP responder 204. Alternatively, if the transactioncoordinator and OCSP responder are co-located, a signature on therequest may not be necessary. In step 7024, OCSP responder 204 verifiesthe signature of the request, checks its local repository to determinethe validity of its relying customer's certificate, and sends a responseback concerning that certificate's status to transaction coordinator 202_(RP).

It should be noted that, as part of system operation, relying customers108 will often need to validate the certificate of a subscribingcustomer 106 that is a customer of a participant other than relyingparticipant 104. Because, in that case, relying participant 104 is notthe issuing participant that issued the certificate to be validated, itdoes not have first hand knowledge of that certificate's status.

In a preferred embodiment, the present system addresses this problem byhaving each participant that receives an OCSP request for a certificateissued by another participant, forward the request to the issuingparticipant for that certificate. In particular in step 7026, relyingparticipant 104 determines the subscribing customer's issuingparticipant. If the subscribing customer is a customer of a differentparticipant, relying participant 104 generates a signed validationrequest for the subscribing customer's certificate and sends it to theidentified issuing participant 102 along with its own certificate.Alternatively, rather than sign the validation request, the relyingparticipant may instead provide client-side authentication to issuingparticipant 102 as, for example, in the OCSP-proxy centric modeldescribed below.

If the subscribing customer and the relying customer are both customersof the same participant, validation of the subscribing customer'scertificate is handled by local-handler module 602, as described above.

In step 7028, issuing participant 102 checks its customer database 214_(IP) to make sure that the request was signed by an entity authorizedto make the request. In step 7030, issuing participant 102 stores thereceived raw transaction (i.e., the unparsed request, signature, andaccompanying certificate) in its raw transaction log 212 _(IP). In step7032, issuing participant 102 stores relevant billing data for therequest in its billing log 208. Alternatively, billing data may beextracted from the raw-transaction log by an off-line process toincrease system performance.

In step 7034, issuing participant 102 verifies transaction coordinator202 _(RP)'s signature on the request using the relying participant'stransaction coordinator certificate (sent with the request) and the rootpublic key (which may be stored in hardware security module 218 _(IP)).In step 7036, the issuing participant's transaction coordinator 202_(IP) generates a signed OCSP request for the relying participant'stransaction coordinator certificate and sends the request to root entity110.

In step 7038, transaction coordinator 202 _(R) of root entity 110receives the request and stores the raw request in its raw transactionlog 212 _(R). In step 7040, transaction coordinator 202 _(R) storesbilling data for the request in billing data log 208 _(R). In step 7042,transaction coordinator 202 _(R) verifies the signature on the requestand then sends the request to OCSP responder 204 _(R). In step 7044,OCSP responder 204 _(R) checks its local repository to determine thestatus of the subject certificate and sends a response back concerningits status to transaction coordinator 202 _(R). In step 7046,transaction coordinator 202 _(R) sends a signed response to transactioncoordinator 202 _(IP) indicating the status of the relying participant'stransaction coordinator certificate.

In step 7048, transaction coordinator 202 _(IP) of issuing participant102 stores the OCSP response from root entity 110 in raw transaction log212 _(IP) for non-repudiation purposes. In step 7050, transactioncoordinator 202 _(IP) generates an OCSP request for the subscribingcustomer's certificate, signs it, and sends it to its own local OCSPresponder 204 _(IP) along with its own certificate. Alternatively, iftransaction coordinator 202 _(IP) and OCSP responder 204 _(IP) areco-located, a signature on the request may not be necessary. Also, ifthe two are co-located, the transaction coordinator may simply act as apass through, as opposed to re-signing requests and responses.

In step 7052, OCSP responder 204 _(IP) verifies the signature on therequest, generates a response, signs it, and returns the signed responseto transaction coordinator 202 _(IP). In step 7054, transactioncoordinator 202 _(RP) verifies the OCSP responder's signature, resignsthe response, and returns it to transaction coordinator 202 _(RP) alongwith its own certificate.

In step 7056, transaction coordinator 202 _(RP), of relying participant104 stores the raw response data received from issuing participant 102in raw transaction log 212 _(RP) for non-repudiation purposes. In step7058, transaction coordinator 202 _(RP) verifies the signature oftransaction coordinator 202 _(IP) on the response using the issuingparticipant's transaction coordinator certificate (sent with therequest) and the root public key (which may be stored in hardwaresecurity module 218 _(RP)). In step 7060, transaction coordinator 202_(RP) generates a signed OCSP request for the issuing participant'stransaction coordinator certificate and sends it to root entity 110.

In step 7062, transaction coordinator 202 _(R) of root entity 110 storesthe raw request data in raw transaction log 212 _(R). In step 7064,transaction coordinator 202 _(R) stores relevant billing data in billinglog 208 _(R). In step 7066, transaction coordinator 202 _(R) verifiesthe signature on the request and sends the request to OCSP responder 204_(R). In step 7068, OCSP responder 204 _(R) checks its local repositoryto determine the status of the issuing participant's transactioncoordinator certificate and sends a response back concerning its statusto transaction coordinator 202 _(R). In step 7070, transactioncoordinator 202 _(R) sends a signed response concerning the status ofthe subject certificate to transaction coordinator 202.

In step 7072, transaction coordinator 202 _(RP) of relying participant104 stores the response in raw transaction log 212 _(RP) fornon-repudiation purposes. At this point, processing of the subscribingcustomer's certificate is complete.

In step 7074, transaction coordinator 202 _(RP) now processes the secondhalf of the request: the issuing participant's certificate, bygenerating a signed OCSP request for the issuing participant'scertificate and sending it to root entity 110.

In step 7076, transaction coordinator 202 _(R) of root entity 110 storesthe raw request data in raw transaction log 212. In step 7078,transaction coordinator 202 _(R) stores relevant billing data in billinglog 208.

In step 7080, transaction coordinator 202 _(R) verifies the signature onthe request and sends the request to OCSP responder 204 _(R). In step7082, OCSP responder 204 _(R) checks its local repository to determinethe status of the subject certificate and sends a response back totransaction coordinator 202 _(R). In step 7084, transaction coordinator202 _(R) sends a signed response to transaction coordinator 202 _(RP).

In step 7086, transaction coordinator 202 _(RP) of relying participant104 stores the response from root entity 110 in raw transaction log 212_(RP) for non-repudiation purposes. In step 7088, transactioncoordinator 202 _(RP) creates an OCSP response from the responsesreceived from transaction coordinator 202 _(IP) of issuing participant102 and its local cache, signs it, and sends it to relying customer 108along with its own certificate.

In step 7090, relying customer 108 verifies the response using theroot's public key certificate stored in hardware security module 230. Instep 7092, relying customer 108 sends a request to transactioncoordinator 202 _(RP) for the relying participant's transactioncoordinator certificate in order to determine if that certificate hasbeen revoked. In step 7094, transaction coordinator 202 _(RP) verifiesthe signature on the request and sends a request to local OCSP responder204 _(RP) to ensure that the relying customer's transaction coordinatorcertificate has not been revoked. In step 7096, local OCSP responder 204responds to this request from transaction coordinator 202 _(RP).

In step 7098, transaction coordinator 202 _(RP), sends an OCSP requestfor the relying participant's transaction coordinator certificate totransaction coordinator 202 _(R) of root entity 110. In step 7100,transaction coordinator 202 _(R) verifies the signature on the requestand checks with local OCSP responder 204 _(R) to determine the status ofthe relying participant's transaction coordinator certificate. In step7102, transaction coordinator 202 _(R) forwards the response receivedfrom local OCSP responder 204 _(R) to transaction coordinator 202 _(RP).

In step 7104, transaction coordinator 202 _(RP) forwards the responsereceived from root entity 110 to relying customer 108. In step 7106,relying customer 108 provides acknowledgment to subscribing customer106.

In connection with steps 7092-7104 above, it should be noted that, aspart of system operation, relying customers 108 will typically need toobtain the status of relying participant 104's transaction coordinatorcertificate. Within the four-corner model, the transaction coordinatorand OCSP responder certificates of issuing participant 102 and relyingparticipant 104 are signed by root entity 110. While root entity 110operates an OCSP responder, this service is accessible only toparticipants. Consequently, relying customer 108 cannot requestvalidation of its relying participant's certificates directly from rootentity 110.

In a preferred embodiment, the present system addresses this problem byhaving each participant 102, 104 operate a root responder proxy. Thisproxy accepts requests from customers on behalf of the root, typicallythrough a different uniform resource locator, forwards the request tothe root over an authenticated secure sockets layer channel, and returnsthe response (still signed by the root) to the requesting party.

The four-corner model described above may also be used to provide awarranty service that warranties the identity of a particular entity(e.g., the subscribing customer) that signed a transaction. Oneembodiment for providing such a warranty service is described below.Additional embodiments for providing warranty services are described inU.S. provisional patent application Ser. No. 60/224,994, filed Aug. 14,2000, entitled Signing Interface Requirements, Smart Card ComplianceRequirements, Warranty Service Functional Requirements, and AdditionalDisclosure, which is hereby incorporated by reference.

FIG. 8 is a diagram of the transaction flow for one preferred embodimentof a warranty service. As shown in FIG. 8, in step 8002, subscribingcustomer 106 creates a hash of date representing a transaction betweensubscribing customer 106 and relying customer 108 and sends the hash tosmart card 226 for signature. In step 8004, smart card 226 signs thedata and returns the signature along with the subscribing customer'scertificate and the issuing participant's certificate. Optionally, thismessage may also include card and signature security data (CSSD) toinject additional security such as protection against duplicatemessages.

In step 8006, subscribing customer 106 sends the signed data, thesignature, the subscribing customer's certificate, and the issuingparticipant's certificate (and optionally the CSSD) to relying customer108. In step 8008, relying customer 108 verifies the signature on thedata sent by subscribing customer 106. Alternatively, verification maybe provided as a service to relying customer 108 by relying participant104. Relying customer 108 then creates a warranty request and transmitsthe request to hardware security module 230 for signature. In step 8010,hardware security module 230 returns the signed request along with acopy of the relying customer's certificate.

In step 8012, relying customer 108 sends the signed warranty request andrelying customer certificate to relying participant 104.

In step 8014, transaction coordinator 202 _(RP) of relying participant104 checks customer database 214 _(RP) to make sure that the request wassigned by an existing customer before processing the request. In step8016, transaction coordinator 202 _(RP) stores the raw transaction datarelating to the transaction (i.e., the “unparsed” request, signature,and accompanying certificate) in raw transaction log 212 _(RP). In step8018, transaction coordinator 202 _(RP) stores relevant billing data inbilling log 208 _(RP). Alternatively, billing data may be extracted fromthe raw transaction log by an off-line process to increase systemperformance.

In step 8020, transaction coordinator 202 _(RP) verifies the relyingcustomer's signature on the request using the relying customer'scertificate (sent with the request), the relying participant'scertificate, and the root public key (both of which may be stored inhardware security module 218 _(RP)). Transaction coordinator 202 thengenerates an OCSP request containing the relying customer's certificate,signs it, and sends it to its local OCSP responder 204 _(RP).Alternatively, if the transaction coordinator and OCSP responder areco-located, a signature on the request may not be necessary.

In step 8022, OCSP responder 204 _(RP) verifies the signature on therequest, check its local repository for the status of the relyingcustomer's certificate, and sends a response concerning that status backto transaction coordinator 202 _(RP).

In step 8024, transaction coordinator 202 _(RP) calls a risk manager 216_(RP) to determine if relying customer 108 is financially authorized tomake the warranty request. If it is, then, in step 8026, transactioncoordinator 202 _(RP) determines the participant responsible forresponding to warranty requests concerning subscribing customer 106(i.e., the participant of which subscribing customer 106 is a customer).In the present example, this entity is issuing participant 102.Transaction coordinator 202 _(RP) then creates a warranty request forsubscribing customer 106, signs it, and sends it to issuing participant102 along with its own certificate. It should be noted that if therelying customer and subscribing customer are both customers of the sameparticipant, the warranty request may instead be processed locally bythe participant.

In step 8028, transaction coordinator 202 _(IP) checks customer database214 _(IP) to make sure that the request was signed by an entityauthorized to make the request. In step 8030, transaction coordinator202 _(IP) stores the raw transaction data (i.e., the “unparsed” request,signature, and accompanying certificate) in raw transaction log 212_(IP). In step 8032, transaction coordinator 202 _(IP) stores relevantbilling data for the request in the billing log 208 _(IP).Alternatively, billing data may be extracted from the raw transactionlog by an off-line process to increase system efficiency. In step 8034,transaction coordinator 202 _(IP) verifies transaction coordinator 202_(RP) 3 s signature on the request using transaction coordinator 202_(RP)'s certificate (sent with the request), and the root public key(which may be stored in hardware security module 218 _(IP)). Transactioncoordinator 202 _(IP) then generates a signed OCSP request for therelying participant's transaction coordinator certificate and sends itto root entity 110.

In step 8036, transaction coordinator 202 _(R) of root entity 110 storesthe raw request in raw transaction log 212 _(R). In step 8038,transaction coordinator 202 _(R) stores relevant billing data for therequest in billing data log 208 _(R). In step 8040, transactioncoordinator 202 _(R) verifies the signature on the request and thensends the request to OCSP responder 204 _(R). OCSP responder 204 _(R)checks its local repository to determine the status of relyingparticipant's transaction coordinator certificate and sends a responseconcerning that status back to transaction coordinator 202 _(R).Transaction coordinator 202 _(R) then sends a signed response back totransaction coordinator 202 _(IP).

In step 8042, transaction coordinator 202 _(IP) of issuing participant102 stores the raw response in raw transaction log 212 _(IP) fornon-repudiation purposes. In step 8044, transaction coordinator 202_(IP) then generates an OCSP request from the request it receivedcontaining the subscribing customer's certificate, signs it, and sendsit to its local OCSP responder 204 _(IP) along with its own certificate.Alternatively, if the transaction coordinator and OCSP responder areco-located, as signature on the request may not be necessary. Also, ifthe two are co-located, the transaction coordinator may simply act as apass through as opposed to re-signing requests or responses.

In step 8046, OCSP responder 204 _(IP) verifies the signature on therequest, generates a response, signs it, and returns the signed responseto transaction coordinator 202 _(IP). In step 8048, transactioncoordinator 202 _(IP) calls risk manager 216 _(IP) to determine whetheror not to issue a warranty for subscribing customer 106. In step 8050,risk manager 216 _(IP) returns a signed message to transactioncoordinator 202 _(IP) indicating whether a warranty should be issued. Instep 8052, transaction coordinator 202 _(IP) stores the signed responsein raw transaction log 212 _(IP).

In step 8054, transaction coordinator 202 _(IP) sends a signed requestto transaction coordinator 202 _(R) of root entity 110 to determine ifissuing participant 102 has enough collateral to issue the warranty. Instep 8056, transaction coordinator 202 _(R) interacts with risk manager216 _(R) to determine if issuing participant 102 is adequatelycollateralized and, if so, decreases issuing participant 102'scollateral level by an amount appropriate for the warranty being issuedand returns a response to issuing participant 102.

In step 8058, transaction coordinator 202 _(IP) verifies transactioncoordinator 202 _(R)'s signature, creates a warranty response, andreturns it to transaction coordinator 202 _(RP) along with itscertificate.

In step 8060, transaction coordinator 202 _(IP) of relying participant104 stores the raw response in raw transaction log 212 _(RP) fornon-repudiation purposes. In step 862, transaction coordinator 202 _(RP)verifies transaction coordinator 202 _(IP)'s signature on the responseusing transaction coordinator 202 _(IP)'s certificate (sent with theresponse), and the root public key (which may be stored in hardwaresecurity module 218 _(RP)). Transaction coordinator 202 _(RP) thencreates a signed OCSP request for the issuing participant's transactioncoordinator certificate and sends it to root entity 110.

In step 8064, transaction coordinator 202 _(R) of root entity 110 storesthe raw request in raw transaction log 212 _(R). In step 8066,transaction coordinator 202 _(R) stores relevant billing data in billinglog 208 _(R). In step 8068, transaction coordinator 202 _(R) verifiesthe signature on the request. Transaction coordinator 202 _(R) thensends the request to its OCSP responder 204 _(R). OCSP responder 204_(R) checks its local repository to determine the status of the subjectcertificate and sends a response back to transaction coordinator 202_(R). Transaction coordinator 202 _(R) then sends a signed response totransaction coordinator 202 _(RP).

In step 8070, transaction coordinator 202 _(RP) of relying participant104 stores the raw response data in raw transaction log 212 _(RP) fornon-repudiation purposes. In step 8072, transaction coordinator 202_(RP) checks with transaction coordinator 202 _(R) of root entity 110 toensure that the issuing participant has sufficient collateral to issuethe warranty.

In step 8074, transaction coordinator 202 _(R) stores the raw request inraw transaction log 212 _(R). In step 8076, transaction coordinator 202_(R) stores relevant billing data in billing log 208 _(R). In step 8078,transaction coordinator 202 _(R) sends a yes or no response totransaction coordinator 202 _(RP) of relying participant 104 concerningwhether issuing participant 102 has sufficient collateral to issue thewarranty.

In step 8080, transaction coordinator 202 _(RP) stores the raw responsedata in raw transaction log 212 _(RP) for non-repudiation purposes. Instep 8082, transaction coordinator 202 _(RP) creates a warranty responsefrom the responses received from transaction coordinator 202 _(IP),signs it, and sends it to relying customer 108 along with transactioncoordinator 202 _(RP)'s certificate.

In step 8084, relying customer 108 verifies the response using the rootpublic key stored in hardware security module 230. In step 8086, relyingcustomer 108 sends a request to transaction coordinator 202 _(RP) fortransaction coordinator 202 _(RP)'s certificate to see if it has beenrevoked.

In step 8088, transaction coordinator 202 _(RP), verifies the signatureon the request and sends a request to its local OCSP responder 204 _(RP)to ensure that relying customer 108's transaction coordinatorcertificate has not been revoked. In step 8090, local OCSP responder 204_(RP), sends a response to this request to transaction coordinator 202_(RP). In step 8092, transaction coordinator 202 _(RP) sends an OCSPrequest for its certificate to transaction coordinator 202 _(R).

In step 8094, transaction coordinator 202 _(R) verifies the signature onthe request and checks with its local OC SP responder 204 _(R) todetermine the status of transaction coordinator 202 _(RP)'s certificate.Transaction coordinator 202 _(R) then forwards the response receivedfrom local OCSP responder 204 _(R) to transaction coordinator 202 _(RP).

In step 8096, transaction coordinator 202 _(RP), forwards the responsereceived from transaction coordinator 202 _(R) to relying customer 108.In step 8098, relying customer 108 sends an acknowledgment tosubscribing customer 106.

In a preferred embodiment, each transaction coordinator 202 providesatomicity, consistency, isolation, and durability to transactionscoordinated by the transaction coordinator. Atomicity means that allactions required to complete a transaction succeed or all fail; thetransaction is an indivisible unit of work. Consistency means that aftera transaction is executed, the system is left in a correct, stablestate, or returns to the state preceding initiation of the transaction.Isolation means that each transaction is unaffected by othertransactions that may execute concurrently. Durability means that theeffects of each transaction are permanent after the transaction iscommitted. The combination of atomicity, consistency, isolation, anddurability are sometimes referred to as ACID properties.

Transaction coordinators 202 preferably provide ACID properties in adistributed computing environment by incorporating a transactionprocessing monitor or component transaction monitor. Suitabletransaction processing monitors may include BEA TUXEDO from BEA Systems,Inc., MSMQ from Microsoft, Top End from NCR Corporation, and Encina fromIBM Transarc. Suitable component transaction monitors may include OrbixOTM from Iona Technologies Inc. and BEA WebLogic from BEA Systems, Inc.

Any combination of steps to be coordinated by a transaction coordinatormay be combined to form a transaction having the ACID properties.Preferably, one or more pre-defined transactions are provided for eachof the process flows depicted in FIGS. 5-7. Thus, for example, the stepsoccurring between the request and response depicted in FIG. 5 may becombined to form a transaction having ACID properties.

In a preferred embodiment, transaction coordinator components interactwith the transaction processing monitor via a transaction processinglibrary. To facilitate a flexible architecture whereby the implementedtransaction processing monitor may be replaced with an alternatetransaction processing monitor, libraries may be written to accesstransaction-processing-monitor functionality regardless of theparticular brand of transaction processing monitor used.

Each of the above-listed transaction processing monitors has certainfeatures that relate to its suitability for incorporation in atransaction coordinator of the present system. For example, TUXEDOtransaction process monitors are designed to provide: (1) ahigh-performance message-passing engine (2) distributed transactionmanagement, allowing clients and servers to participate in a distributedtransaction and to manage two-phase commit processes transparently toapplications (3) an application to transaction manager interfaceallowing developers to write BEA TUXEDO applications regardless of thehardware hosting program (4) dynamic workload balancing thatautomatically generates and manages parallel copies of applications andensures that they are evenly utilized (5) transaction queuing thatallows distributed applications to work together in an asynchronous,connectionless fashion and that prioritizes queues based on messagecontext, content, and time of day (6) data dependent routing thatenables transactions to be processed where the data can be mostefficiently utilized (7) automatic recovery from application failures,transaction failures, network failures, and node failures in which theserver manager restarts the failed process and recovers the failedprogram by rolling back the transaction that was in progress.

MSMQ transaction processing monitors from Microsoft are designed toprovide: (1) full COM component support (2) access from a range ofprogramming languages (e.g. Visual C++, Visual J++) (3) five APIs (open,close, receive, send, and locate) providing advanced message queuingbenefits (4) sliding-window protocols, recoverable storage, dynamicrouting to deliver messages, and on-time, in-order message delivery (5)the ability to be included within transactions that contain otheractivities, such as database updates (6) the ability to commit or abortoperations with other resources to preserve data integrity duringtransactions (7) built-in message encryption, integrity, and signaturesupport and (8) administrators the ability to specify which MSMQ eventsshould create an audit record in the Windows NT Security Log.

MSMQ is typically included as a feature of both MS Windows NT Server,Standard Edition 4.0 and MS Windows NT Server, and Enterprise Edition4.0. If support for more than twenty-five clients, cost-based routing,or the MSMQ Connector is needed, MSMQ is preferably run on NT Server andEnterprise Edition 4.0. It should be noted that although MSMQ is ahigh-performance message-passing engine, it does not have necessaryfeatures of a transaction process monitor, and therefore may not besuitable for use in the present system.

IBM Encina is available from Transarc on many hardware platformsincluding Sun, IBM, Digital Equipment Corp., Hewlett Packard, andWindows. IBM Encina transaction processing monitors are designed toprovide: (1) interoperability to allow the development of distributedtransaction processing applications that integrate a wide variety ofsystems (2) concurrent use of multiple XA-compliant databases orresource managers, such as Oracle, Ingres, Informix, or Sybase throughan X/Open XA application programming interface and provide mainframeLU6.2 interoperability, including sync-level 0, 1, and 2 services,without requiring additional software on the mainframe (3) performanceand reliability required by transaction processing applications (4) anefficient, fully-distributed two-phase commit mechanism (5) automaticload balancing and replication of application servers to increaseperformance and to eliminate single points of failure (6) inheritedsecurity mechanisms of the underlying DCE thereby allowing both clientsand servers to verify the identities and privileges of participants in atransaction (7) additional security mechanisms, including automatedauthorization checking and facilities to allow the construction of audittrail records (8) enterprise-wide scalability in order to support largenumbers of users and large amounts of data and (9) a centralizedadministration facility to permit effective management.

Top End transaction processing monitors are designed to provide: (1)robust middleware (2) distributed transaction management (3)client/server interaction (4) reliable file transfer (5) dynamicworkload balancing (6) recoverable transaction queuing (7) applicationparallelization (8) two-phase commit processing (9) automatic recovery(10) message-sensitive routing (11) multiple database support (MicrosoftSQL Server, Oracle, and Sybase) and (12) Internet applicationscalability and availability.

In a preferred embodiment, each transaction coordinator in the presentsystem is adapted to provide a plurality of security services including:authentication, authorization, session security, message security,non-repudiation, and auditing.

In a preferred embodiment, the transaction coordinator uses PKIXauthentication based on a PKI defined by root entity 110. Otherauthentication mechanisms for services outside the present system may besupported as determined by the entity operating the transactioncoordinator.

In a preferred embodiment, authentication is provided through the use ofdigital signatures. Authentication may take place at the session level,the message level, or both.

In a preferred embodiment, the secure socket layer protocol providessession level authentication. The secure sockets layer protocol consistsof two phases: server-side authentication and optional client-sideauthentication. A given transaction coordinator 202 acts as a serverwhen it receives requests from a customer or another transactioncoordinator and as a client when it transmits a request to anothertransaction coordinator.

FIG. 9 depicts server-side authentication. A server 90 receives arequest from a client 95 (step 9002), and sends its utility certificateto the client (step 9004). In step 9006, client 95 generates a publickey, encrypts it with the server's public key and sends it to server 90(step 9006). In step 9008, server 90 uses its private key to recover thepublic key sent by client 95, and authenticates itself to client 95 byreturning a message authenticated with the public key received from theclient. Subsequent data is encrypted and authenticated with keys derivedfrom the client-generated public key.

Secure socket layer server-side authentication allows client 95 to knowwith whom it is communicating. Server-side authentication is preferablyrequired for all sessions over which network transactions take place. Inorder to authenticate server 90, client 95 must possess the public keycertificate of the root certificate authority in server 90's utilitycertificate chain.

FIG. 10 depicts optional client-side authentication. In step 10002,server 90 sends a challenge to client 95. Client 95 authenticates itselfto server 90 by signing the challenge with its private key and returningthe signed challenge, with its public key certificate, to the server(step 10004).

Secure socket layer client-side authentication ensures that client 95possesses a valid utility certificate and the accompanying private key.As noted, in a preferred embodiment, secure socket layer client-sideauthentication is optional but is employed if relying and issuingparticipants 104 and 102 do not require digitally signed requests fromclients 95. Transaction coordinators 202 _(IP), 202 _(RP), and 202 _(R)must possess the public key certificate of the root certificateauthority in the client's utility certificate chain in order todetermine that client 95 holds a valid root certificate.

In a preferred embodiment, at the session level, issuing participant 102and relying participant 104 authenticate themselves to their customerclients. Issuing participant 102 and relying participant 104 may alsorequire customer clients to authenticate themselves to transactioncoordinators 202 _(IP), 202 _(RP), and 202 _(R) at the time a session isestablished. Thus, if client 95 is not an authorized customer of theparticipant with which it is communicating, the transaction coordinatorfor that participant may terminate the session before processing amessage. Participants may also require customer client-sideauthentication at the session level in lieu of requiring message levelauthentication.

As noted, authentication between transaction coordinators 202 _(IP), 202_(RP), and 202 _(R) may occur either at the session level or at themessage level, or both. In contrast, relying customers are preferablyrequired to provide authentication at the message level by digitallysigning all requests sent to transaction coordinator 202 _(RP). However,as previously mentioned, a participant may also require relyingcustomers to provide client-side authentication at the session level.

FIG. 11 is a composite block/flow diagram illustrating a preferredmessage authentication process. As will be described, this processoperates to authenticate messages (responses or requests) sent totransaction coordinators 202 by applying a digital signature to datacontained in the message.

In step 1102, an authentication module 408 calls hardware securitymodule 218 to verify the signature on a received message using thesender's public key certificate typically sent with the message. In step1104, authentication module 408 calls hardware security module 206 tocheck that the sender possesses a valid root warranty certificate byvalidating the sender's certificate chain, beginning with the root'scertificate in the sender's chain. Portions of the sender's chain, suchas the sender's public key certificate, are sent with the message. Otherportions of the chain may be previously stored in HSM 206 and/orcustomer database 214, such as the root's certificate.

In step 1106, authentication module 408 calls a time source 11 to obtainthe current time and verify that none of the certificates comprising thesender's chain have expired. All participants and root entity 110 arepreferably provided with synchronized time sources.

In step 1108, authentication module 408 calls OCSP responder 204 tocheck that the certificates in the signer's chain, other than thosestored in hardware security module 218, have not been revoked.

Message authentication provides a stronger level of authentication thansession authentication. Session authentication uses utility keys. Ingeneral, OCSP checks are not performed on utility keys, thereforeneither a client nor a server will learn during the authenticationprocess if an SSL certificate has been revoked. In addition, utilitykeys are stored unprotected so that anyone in possession of the token onwhich the key is stored can masquerade as the authorized user. Warrantykeys, on the other hand, which are used to provide messageauthentication, are protected so that merely possessing the token is notsufficient to gain access to the key and masquerade as the authorizeduser.

In a preferred embodiment, customer authorization check module 418 (seeFIG. 5) checks to make sure the requestor of a service is authorized toreceive that service. For purposes of determining authorization, therequestor's identity may be determined from session level authenticationor message level authentication. Preferably, customer authorizationcheck module 418 performs an authorization check by extracting theuser's authenticated identity or distinguished name from its presentedutility or warranty certificate, and comparing this against a list ofauthorized users in customer database 214. In a preferred embodiment,the customer authorization check may be based on a part of thedistinguished name, such as any user with a distinguished namesubordinate to the financial institution's certificate authority'sdistinguished name, or it can be based on the entire distinguished name,such that only specific users are authorized.

Customer authorization check module 418 may perform authorization checksat multiple levels. For example, it may have the capability to allow ordeny services at the user level, or to allow or deny services based onfiner criteria, such as the amount of collateral a user has.

In a preferred embodiment, transaction coordinators 202 provide sessionsecurity using a secure socket layer (SSL). SSL typically provide threelevels of session security: confidentiality, data integrity, and sessionauthentication. Preferably, all communications to and from transactioncoordinators 202 are encrypted using SSL.

Message security in the present system is preferably provided throughthe use of digital signatures. Digital signatures provide two levels ofmessage security: authentication and data integrity. Digital signaturestypically provide authentication through the use of protected privatekeys, which are used for signing messages.

As noted above, digital signatures preferably provide data integritythrough the use of a hash or message digest that is generated during thesignature process. Message digests provide a “fingerprint” of the datasuch that if any bit of the signed data is modified, a different“fingerprint” will result and the recipient of the data will not be ableto verify the signature.

In a preferred embodiment, confidentiality is provided at the sessionlevel for all root communications. The transaction coordinatorpreferably complies with confidentiality rules specified by root entity110.

In a preferred embodiment, each transaction coordinator 202 records alldata needed to ensure non-repudiation of a performed service in logs andensures the integrity of those logs. For example, relying participant104 preferably provides such non-repudiation for all services itperforms for relying customer 108. Thus, for each service performed,transaction coordinator 202 _(RP) not only provides a response torelying customer 108 but also retains all data necessary to ensure thatnone of the parties involved in performing the service can repudiatehaving provided the service.

In a preferred embodiment, digitally signed messages provide the basisfor this non-repudiation. As noted, for example, in the context of thevalidation service described above, transaction coordinators 202maintain a log of all received messages for non-repudiation purposes.Preferably, transaction coordinators 202 log messages exactly asreceived and do not parse, modify, or store messages in any format otherthan the format in which they were received. Modification of receivedmessages renders the message's digital signature unverifiable and thusmakes the message unsuitable for non-repudiation purposes.

In a preferred embodiment, each received message is time stamped as partof the non-repudiation service. Responses are associated withauthorization checks performed at a certain point in time. Preferably,the time of the authorization check is a signed attribute in theresponse and is captured in raw transaction log 212.

In a preferred embodiment, transaction coordinator 202 also logsinformation for auditing purposes. Security audit logs may be used todetect potential attacks against the system, such as a suspicious numberof requests from non-customers or a suspicious number of invalidsignatures. Security audit logs may also assist when a key compromiseoccurs because a key may be compromised before it is reported and itsassociated certificate is revoked. The security audit logs maypreferably be used to determine if transactions occurred using acompromised key.

An audit trail is maintained for purposes of dispute resolution,non-repudiation, and billings. In a preferred embodiment, a transactioncoordinator logs every message that it sends or receives and logs theentire message. Messages may be logged in “raw” format. Alternatively,the transaction coordinator may break the message into its constituentparts and store it in a schema such that the entire message can bereconstructed in a manner that preserves the signature. In a preferredembodiment, logs are of such a nature that log entries cannot befalsified (added/deleted/altered) without being detected. In addition,if a transaction coordinator logs a message in raw format, it preferablyincludes the capability to convert the raw data into a format readableby a COTS solution. This may be a loosely coupled utility or a part ofthe transaction coordinator functionality that runs as a separate andperhaps lower priority/background process. It may also run on anentirely separate system. The logs may contain other data related to thetransport and the session. As an example this may include,sender/recipient IP address, the URL of the post, SMTP header etc.

Transport services component 306 (shown in FIG. 3) preferably comprisesa secure communications component that establishes a secure socket layersession between transaction coordinator 202 and the entity with which itis communicating. In a preferred embodiment, the secure communicationcomponent performs session authentication, as described above. Thus,when transaction coordinator 202 acts as a server 90, the securecommunications component provides server-side session authentication andmay request client-side session authentication. In contrast, whentransaction coordinator 202 acts as a client 95, the securecommunications component is responsible for authenticating server 90.

As a client, transaction coordinator 202 is also preferably responsiblefor establishing session security by generating a session key andsending the key, which is encrypted with the server's public key, to thetransaction coordinator server with which it wants to communicate.Subsequent communications between the two parties are encrypted withthat session key.

FIG. 12 is a composite block/flow diagram that depicts a preferredembodiment of the security-relevant flows associated with components oftransaction coordinators 202. As shown in FIG. 12, in step 1202, arequest is received by transport services component 306. In step 1204,transport services component 306 delivers the request to request manager304. Preferably, request manager 304 ensures that all security-relatedfunctions are performed on incoming messages before the messages areprocessed.

In step 1206, request manager calls logging component 320 to log the rawrequest data. Logging component 320 gathers the data required to supportnon-repudiation and auditing. As noted above, all requests and responsesare preferably logged as received.

In step 1208, request manager 304 determines if a signature on therequest is required. In step 1210, if request manager 304 determinesthat the request does not need to be signed, request manager 304 callscustomer authorization check module 54 with the client's utilitycertificate.

In step 1212, if request manager 304 determines that a signature isrequired, request manager 304 calls customer authentication module 408.In step 1214, customer authentication module 408 verifies the signatureon the request and validates the certificate chain by calling signingcomponent 324.

Preferably, signing component 324 provides message security and supportsthe session and message authentication services. Signing component 324interfaces with hardware security module 218, which performs allcryptographic functions. Root 110 preferably specifies the digitalsignature method that will be used to sign all transactions. Signingcomponent 324 preferably interfaces with hardware security module 218 toperform all cryptographic functions involved in the signatureverification process.

In step 1216, customer authentication module 408 checks the status ofthe customer's warranty certificate by sending a request to OCSPresponder 204 via certificate status check component 414, as describedabove.

In step 1218, customer authentication module 110 calls customerauthorization check module 418 with the customer's warranty certificate.In step 1220, customer authorization check module 418 checks customerdatabase 214 to make sure the request came from a customer authorized toobtain the requested service. In step 1222, a response regardingauthorization is returned to request manager 304 and processing ofsystem provided services continues as described above.

Preferred security requirements for network communications betweentransaction coordinators and the following entities: customers, OCSPresponders, and other transaction coordinators will now be described.These preferred requirements are described in the context of an examplein which relying customer 108 submits a request to relying participant104.

When transaction coordinator 202 _(RP) of relying participant 104receives a request from a relying customer 108, transaction coordinator202 _(RP) authenticates the request. Signatures are typically requiredon all messages sent to transaction coordinator 202 _(RP) by relyingcustomer 108. In addition, transaction coordinator 202 _(RP) may requirerelying customer 108 to provide secure socket layer client-side sessionauthentication.

Preferably, transaction coordinator 202 _(RP) provides authentication ofall messages it sends to relying customer 108. In addition, transactioncoordinator 202 _(RP) provides secure socket layer server-side sessionauthentication when any session is established with relying customer108.

In a preferred embodiment, transaction coordinator 202 _(RP) performsauthorization checks to determine if relying customer 108 is an existingcustomer of relying participant 104. Transaction coordinator 202 _(RP)may also perform authorization checks to determine if relying customer108 is authorized to receive the type or level of service beingrequested. Preferably, relying customer 108 has an entry in customerdatabase 214 _(RP) that lists the services to which it is entitled.Preferably, relying customer 108 is identified by a distinguished nameas it exists in its warranty certificate and may also be identified byits distinguished name as it exists in its utility certificate if securesocket layer client-side session authentication is employed. This aspectof the transaction coordinator may be integrated with COTS accesscontrol/authorization packages.

In a preferred embodiment, transmissions between relying customer 108and transaction coordinator 202 _(RP) are encrypted in accordance withspecifications specified by root entity 100 and server-sideauthentication is required.

Typically, messages exchanged between relying customer 108 andtransaction coordinator 202 _(RP) are digitally signed. Preferably,transaction coordinator 202 _(RP) verifies all signed messages received,validates the certificate chain, and ensures that the certificateswithin the chain have not been revoked. In addition, transactioncoordinator 202 _(RP) signs all messages it sends to relying customer108.

In a preferred embodiment, transaction coordinator 202 _(RP) provides anon-repudiation service for relying customer 108. Transactioncoordinator 202 _(RP) typically logs all responses relating to requestsfor service received from any root component. This includes othercomponents of transaction coordinator 202 _(RP) as well as components ofother participants and root 110. Preferably, relying participant 104logs all requests for services from relying customer 108 and allacknowledgments received from relying customer 108 indicating thereceipt of a response in order to protect itself from repudiation claimsfrom its customers.

In a preferred embodiment, transaction coordinator 202 _(RP) logs allrequests for services from relying customer 108 for auditing purposes.Accordingly, a system administrator can detect potential attacks againstthe system and determine if requests for services were received after akey compromise occurred. Auditing of requests may also be used tosupport any billing disputes that may arise.

In a preferred embodiment, transaction coordinators 202 _(IP), 202_(RP), and 202 _(R) communicate respectively with OCSP responders 204_(IP), 204 _(RP), and 204 _(R) only, i.e., OCSP responders that arewithin their financial institution. To request a response from an OCSPresponder 204 at another financial institution, communications mustpreferably go through the other financial institution's transactioncoordinator 202.

Preferably, OCSP responders 204 _(IP), 204 _(RP) and 204 _(R) know theidentity of the entity from which they are receiving a request andtransaction coordinators 202 _(IP), 202 _(RP), and 202 _(R) know theidentity of the entity from which they are receiving an OCSP response.Preferably, co-located transaction coordinators 202 _(IP), 202 _(RP),and 202 _(R) and OCSP responders 204 _(IP), 204 _(RP) and 204 _(R) knowthat they are receiving messages from a local process without anyexplicit authentication. In this case, neither secure socket layerauthentication nor signed requests are required. However, OCSPresponders 204 _(IP), 204 _(RP) and 204 _(R) may typically sign allresponses and transaction coordinators 202 _(IP), 202 _(RP), and 202_(R) may typically accept signed responses in accordance with theInternet PKI OCSP specification.

If transaction coordinators 202 _(IP), 202 _(RP), and 202 _(R) and OCSPresponders 204 _(IP), 20 _(RP), and 204 _(R) are not co-located andcannot ascertain unambiguously with whom they are communicating,authentication between the components is preferably required.Authentication of requests may be either at the session level or themessage level. Authentication of responses is preferably at the messagelevel and may be at the session level, as well.

It should be recognized that transaction coordinators 202 _(IP), 202_(RP), and 202 _(R) do not typically perform authorization checks onOCSP responders 204 _(IP), 204 _(RP), and 204 _(R) since OCSP responders204 _(IP), 204 _(RP), and 204 _(R) do not typically request servicesfrom transaction coordinators 202 _(IP), 202 _(RP), and 202 _(R).

Because OCSP responders 204 are preferably co-located with theirrespective transaction coordinators 202, transmission securitymechanisms do not typically have to be provided for communicationsbetween them. Because the two components are contained within a physicalenvironment that is completely under the control of one financialinstitution, protection can preferably be provided through policy asopposed to implementation of security mechanisms.

However, if these components are not co-located, the transmissions arepreferably protected against network attacks that could compromise theconfidentiality or the integrity of the transmissions. Preferably, SSLis used to provide this protection.

In a preferred embodiment, each OCSP responder 204 is co-located withits respective transaction coordinator 202 and transaction coordinator202 therefore need not sign OCSP requests. However, OCSP responder 204may sign responses if required by specifications specified by rootentity 110.

In cases where OCSP responses are signed, they are preferably loggedwith the signature of the responder intact, in particular when theresponse is directly related to the service being provided. However, iftransaction coordinator 202 has requested an OCSP response as part of anauthentication check on a request for service, the OCSP response istypically not logged for non-repudiation purposes. This is because theOCSP check is performed to determine whether or not to process theincoming request, not as part of processing the request itself. Onlyinformation relating to the processing of the request is necessary toretain for non-repudiation purposes. In a preferred embodiment, localOCSP responses are typically only logged when relying participant 104 isalso issuing participant 102 of the certificate in question and the OCSPrequest is part of the process for providing a service, e.g., checkingthe subscribing customer's certificate during a validation request forthat certificate.

In a preferred embodiment, there are no requirements to log OCSPresponses for security auditing purposes because OCSP responders 204 donot request services of transaction coordinators 202. In addition, thereare no requirements to log OCSP requests generated by transactioncoordinators 202 for security auditing purposes because transactioncoordinator 202 cannot audit itself.

Preferably, transaction coordinators authenticate all requests fromother transaction coordinators. This is typically accomplished either bysecure socket layer client-side authentication or by a financialinstitution configuring its transaction coordinator to requiresignatures on all requests from other transaction coordinators.

In a preferred embodiment, a first transaction coordinator that receivesa request from a second transaction coordinator performs anauthorization check to determine if the requesting transactioncoordinator is authorized to make the request. This authorization checkis facilitated by providing all authorized transaction coordinators 202_(IP), 202 _(RP), and 202 _(R) with an entry in the customer database ofthe transaction coordinator from which they desire to obtain service. Iftransaction coordinator 202 from whom services are being requestedrequires a signature, the requestor may preferably be identified by itsdistinguished name as it exists in its warranty certificate. If not,identification from its utility certificate should preferably bepermitted only if secure socket layer client-side authentication isrequired.

Preferably, transmissions between relying customer 108 and transactioncoordinator 202 _(RP), are encrypted and server-side sessionauthentication is required.

A participant may require that all requests sent to its transactioncoordinator from other transaction coordinators be signed. In lieu ofthis, a participant may require secure socket layer client-side sessionauthentication. Preferably, transaction coordinators 202 _(IP), 202_(RP), and 202 _(R) sign all responses being sent to other transactioncoordinators.

Preferably, transaction coordinators 202 _(IP), 202 _(RP), and 202 _(R)provide a non-repudiation service. To this end, transaction coordinators202 _(IP), 202 _(RP), and 202 _(R) log all responses relating to arequest for service received from other transaction coordinators.

Preferably, all requests for services received by transactioncoordinators 202 _(IP), 202 _(RP), and 202 _(R) will be logged forauditing purposes. This enables a system administrator to detectpotential attacks against the system and also enables the systemadministrator to determine if requests for services were received aftera key compromise occurred. Auditing of requests may also be used tosupport any billing disputes that may arise.

Preferred architectural components of a transaction coordinator are nowdiscussed in greater detail.

Components of a transaction coordinator are preferably implemented ascustomized software code although other software products may be used asdescribed herein. In addition to this code, a participant may write andimplement its own additional service modules. Thus, participants mayimplement their own business specific rules for the certificate statuscheck service described above and other services that may be offered viathe four-corner model.

In a preferred embodiment, a customer software development kit is usedas a tool-set to facilitate the interface between transactioncoordinator 202 and customers or other transaction coordinators. Thesoftware development kit is preferably integrated with transportservices component 306. The software development kit is preferablyadapted to intercept all hyper-text transfer protocol requests destinedfor an application's original web server at a web site maintained byrelying customer 108. The software development kit preferably determineswhether the message needs to be signed based on a defined set of rules.The customer software development kit also authenticates signatures andpublic key certificates with the help of hardware security module 230. Apreferred embodiment of one such SDK is described in copending U.S.patent application Ser. No. 09/657,604, filed Sep. 8, 2000, entitledSystem and Method for Facilitating Access By Sellers toCertificate-Related and Other Services, which is hereby incorporated byreference.

Depending upon the breadth of the features provided by the softwaredevelopment kit, its usage may preferably be expanded to other areas oftransaction coordinator operation. Certain modifications and additionalfunctionality are typically required in order for the softwaredevelopment kit to be used within the transaction coordinator.

A Microsoft™ SQL server may preferably be used as the database forstoring billing data. Preferably, transaction coordinator 202 is adaptedto interact with the server via a database library. Alternatively,interaction with the server may be done using JAVA™ DatabaseConnectivity if the transaction coordinator development is done inJAVA™. In addition, database libraries may be written for other serversthereby permitting the replacement of a Microsoft SQL server by anotherdatabase without impacting transaction coordinator 202.

Preferably, Microsoft's MS SQL Server provides the following featuresand functionality: (1) Online Analytical Processing (OLAP) Services toefficiently analyze complex information essential to reporting, dataanalysis, decision support, and data modeling (2) on-disk storagearchitecture (3) a Multiphase Query Optimizer (4) auto statistics toenable the query optimizer to use the latest information and to increasequery efficiency (5) active backup to provide high performance onlinebackup with minimal impact on operational systems (6) merge replicationto allow users to work independently, then combine their work later (7)built-in priority-based conflict resolution to resolve merge conflicts(8) ability to publish data on the Web (9) a data transformation serviceto simplify the process of importing and transforming data frommultiple, heterogeneous sources (10) ability to check physical andlogical database consistency (11) dynamic row-level locking (12) a queryoptimizer that manages statistics gathering and guaranteeing anefficient plan (13) an intra-query parallel execution of a single queryacross multiple processors to improve performance; steps in a singlequery are executed in parallel thereby delivering an optimum responsetime (14) a redesigned query processor to better support the largedatabases and complex queries found in decision support, datawarehousing, and Online Analytical Processing applications (15) sortspeed (16) multiple triggers per table and direct recursion of triggers(17) dynamic memory to optimize memory allocation and usage and dynamicmemory management (18) parallel backup and the ability to restoreutilities scale at device speeds (19) smart read-ahead logic to improveperformance and to eliminate the need for manual tuning and (20)run-time checks of critical structures.

Preferably, adequate data is captured and stored to allow the entitythat maintains a transaction coordinator to generate billing invoices ona per transaction basis. To this end, in a preferred embodiment, eachand every incoming and outgoing message generated by a transactioncoordinator, in its entirety, is stored in successive records in adatabase. Such messages include: all requests received, all requestsmade, all responses generated, and all responses received. This ensuresavailability of all the necessary data to generate invoices on a pertransaction basis.

Preferably, transaction coordinator 202 records billing data in acentralized general fashion. Participants may obtain records by writingtheir own routines to extract the billing data relevant to theparticipant from the centralized billing data. In addition to providingdata in the database, data may also be provided in EXCEL™ spreadsheets.

In a preferred embodiment, TymeServe Network Time Server (“TYMSYNC”)™ byDatum Inc. is used as the transaction coordinator's time stampingcomponent. TYMSYNC is a time synchronization package that acquires timefrom the Global Positioning System Naystar satellite constellation withabsolute accuracy to the nearest microsecond relative to the UniversalTime Coordinator as maintained by the United States Naval Observatory.This product may be adapted to synchronize workstations in TCP/IP(transmission control protocol over internet protocol) and LAN (localarea network) networks. Preferably, time is distributed within thenetwork using the Network Time Protocol. TYMSYNC may be configured tocontinuously synchronize a computer system's clock to the Universal TimeCoordinator. The times when requests and responses are generated andwhen messages are received and sent are preferably stored fornon-repudiation and auditing purposes.

In a preferred embodiment, all communications with transactioncoordinator 202 are conducted over secure connections. Preferably, thesecure socket layer encryption scheme for synchronous communications isused. Secure socket layers are used in a fashion compatible withcommercial/web server implementations and provide security and privacyover electronic networks such as the Internet. Secure socket layers areapplication independent, thereby allowing protocols to be layeredtransparently on top of them.

Secure socket layers provide confidentiality, data integrity, andauthentication for all network communications. Secure socket layerstypically ensure confidentiality by encrypting all data being passedbetween the communicating entities. When a secure socket layer-enabledclient 95 and server 90 first communicate, they agree on a protocolversion and select encryption algorithms. Preferably, network endorsedencryption algorithms and key lengths are specified by root entity 110.

Secure socket layers also typically ensure data integrity through theuse of encryption. If a message does not decrypt correctly, therecipient can tell that someone has tampered with the message.

Secure sockets layers also support server and client authentication,negotiate encryption keys, and authenticate the server before data isexchanged by the higher-level application. Authentication is preferablyprovided through the use of digital signatures and public keycertificates, which are exchanged at the time an electroniccommunication session is first established.

In a preferred embodiment, each transaction coordinator is capable ofaccepting and sending messages over the public Internet using SMTP tosend S/MIME messages and communicating via the HTTP protocol over anSSLv3 connection (HTTPS). In other words, each transaction coordinatoris preferably adapted to support the following two modes ofcommunication:

HTTP over Secure Sockets Layer (SSLv3)—For synchronous communications(i.e. HTTPS). HTTPS is a hypertext transfer protocol that incorporatessecure sockets layer between Web servers and Web browsers in order totransfer Web pages securely. Use of HTTP keep alive is recommended.

S/MIME v2—For asynchronous communication using SMTP.

In a preferred embodiment, each transaction coordinator acts as an HTTPSserver during communications with the relying customer and as an HTTPSclient when it makes a request to a transaction coordinator at anotherfinancial institution. In either mode, all SSL communication forcredential status checking may employ only server authentication.

In a preferred embodiment, each transaction coordinator may acceptmessages delivered via other transport protocols (e.g., IIOP) approvedby root entity 110. In addition, participants may implement othertransport protocols locally by arrangement. In the absence of prioragreement, however, only HTTPS support should be assumed.

In a preferred embodiment, Valicert's™ OCSP responder is used forcertificate status check service 312. However, access to OCSP responder204 may be achieved using libraries. Thus, by writing new libraries, newOCSP responder vendors may be implemented.

Preferably, OCSP responder 204 determines certificate status withoutusing a certificate revocation list. OCSP responder 204 may move most ofthe processing involved to a certificate authority, a component thatissues, verifies, and revokes certificates, and eliminate the need todownload potentially large certificate revocation lists. Alternatively,these functionalities may be divided among different components whichmay be provided with separate signing keys. For example, the function ofissuing certificates may be separated from the revocation function, andcomponents for performing these functions may be provided with separatesigning keys.

In a preferred embodiment, a hardware security module is used as asigning component. The hardware security module is preferably ahigh-speed device for signing and verifying signatures. The hardwaresecurity module is typically a networked hardware device that providescryptographic services to authenticated entities. A suitable hardwaresecurity module is manufactured by NCipher.

In a preferred embodiment, transaction coordinator 202 is alwaysavailable to process requests during its normal operating times, whichmay be twenty-four hours a day seven days a week. To make sure thesystem meets availability requirements, a detailed requirement analysisof system-availability should be conducted. Because differentparticipants may have different requirements, many different types offailures may occur. As is known, many different hardware and softwarevendors offer different options for high-availability systems. However,these options may or may not be available for the hardware and softwarethat is chosen by a given financial institution.

There are a number of known potential hardware failures that may affecta transaction coordinator. For example, the power supply to the servermay fail. Preferably, a multiple redundant hot-swap power supplyautomatically swaps to a redundant power supply. If the server fails orcrashes, the transaction coordinator preferably provides for highavailability clustering for automatic fail over. In addition, thetransaction coordinator preferably comprises a self re-start capabilityfor automatically rebooting the server in the event of a networkoperating system (NOS) hang.

The transaction coordinator also preferably comprises multiple redundanthot-swap disk drives and a disk array controller to handle disk failureor crashes. The transaction coordinator also comprises a networkinterface to provide support for redundant network interface cards(NICs) in the event of NIC failure. In the event of cooling systemfailure, the transaction coordinator preferably uses redundant hot-swapcooling systems comprising hot swappable redundant fans which areindividually removable. The transaction coordinator also preferablycomprises an Intelligent Platform Management Interface to detecthardware and software failures. The Intelligent Platform ManagementInterface is an open specification which simplifies and standardizescommunications for device management. In the event of memory corruption,the transaction preferably uses self-correcting memory. Theself-correcting memory is preferably a managed error checking andcorrecting system memory and cache memory.

In the event of application crashes, transaction coordinator 202preferably uses transaction processing monitoring to restart theapplication. The transaction coordinator may also run redundant copiesof an application and the transaction process monitor may transfertransactions to the redundant copies. Certain application availabilityfeatures may require that the application to be coded in a specific waywhich may also help address application crashes.

In the event of an operating system crash, transactions are preferablytransferred to a standby machine that is supported by the network.Directory services, including middleware like CORBA, may also be used tore-direct any new transaction requests to the new machine.

In addition to the hardware and the software availability products, amonitoring infrastructure is preferably used to monitor the applicationsand the network.

In a preferred embodiment, a software monitoring tool (such as Trivoli)is used to monitor applications. This tool is preferably configured topage the administrator in the event of application failure. A networkmonitoring system (such as that made by NetView) may also be used toallow administrators to monitor the network.

Preferably, custom written application daemons are used to simulatetransactions. If these transactions fail, system administrators may beinformed. Also, database vendor tools may be used for databasemonitoring. Most databases provide database-monitoring tools that detectdeadlocks and other databases problems.

A distribution approach for the transaction coordinator may preferablybe defined that is a function of what root entity 110 wishes todistribute to participants. Application distribution may typically beperformed via Web-download from root entity 110. The Web-downloadmechanism may provide for selective download, authentication, andtracking

In a preferred embodiment, the transaction coordinator may be adapted tosupport integration with existing operational systems such as CICS, IMSand other legacy systems.

Participants may choose to use the entire transaction coordinatorarchitecture and functionality described above, or may instead choose touse components of the transaction coordinator and add their ownimplementations to those components. The Web-download approach ispreferably configured to fulfill the varying requirements ofparticipants. The download mechanism preferably provides at least threedownload options: (1) a download transaction coordinator executableoption (2) a source code or binaries of the transaction coordinatoroption and (3) a source code of transaction coordinator classes option.

The first option preferably accommodates participants that choose to usethe transaction coordinator in its entirety. This option providesoptions for different platforms. The second option preferablyaccommodates participants that choose to plug components of thetransaction coordinator described above into their own implementations.This download mechanism also provides options for different platforms.The third option preferably accommodates financial institutions that optfor heavy-duty development and choose only to use certain pieces ofimplementation of the transaction coordinator described above.

Preferably, the download mechanism allows financial institutions to notonly download the executable, but also the source code. Because thedownloaded executable may be used on its own and the source code may beused to develop other custom applications, root entity 110 preferablyprovides download access only to those institutions that are trustedpartners with root entity 110 and hence are authorized to use thetransaction coordinator. Preferably, this is achieved via anauthentication/authorization process.

Root entity 110 may preferably track which participants downloadparticular components of the transaction coordinator. This way rootentity 110 may determine the versions of the transaction coordinatorand/or its components that are being used at any given time. Root entity110 may use this information to (1) charge a fee from the financialinstitutions for the downloaded component(s) and to (2) track versionsof the transaction coordinator for maintenance purposes.

Preferably, the transaction coordinator is adapted to be scalable toaccommodate a growing user base without significant performancedegradation. One step in fulfilling the scalability requirements for anapplication is to forecast the potential growth in the user base. Ingeneral, an application with a distributed architecture facilitateshigher scalability by allowing distributed multiple instances of heavilyloaded components to be running at a given time. The transactioncoordinator architecture is preferably a distributed one and, therefore,supports scalability. In addition, the load-capacity of the transactioncoordinator is preferably base-lined on a chosen development machine.This information is used to select appropriate hardware to support theanticipated number of transactions. Preferably, the transactioncoordinator (and OCSP responder) are adapted to reliably handle up to1000 validation transactions per minute.

As noted above, OCSP checks are typically not performed on utilitycertificates. If signatures are not required on requests, there is nomechanism in place to ensure that the secure socket layer client-sidecertificates have not been revoked. Preferably, if a secure socket layercertificate has been revoked, financial institutions are informed out ofband (e.g., a broadcast message) and the affected users are removed fromthe participant's customer database.

Each transaction coordinator typically trusts some set of certificatesthat are stored on its hardware security module. No OCSP checks areperformed on these certificates. If a revoked certificate exists on ahardware security module, it will not be detected during on-lineprocessing. Preferably, financial institutions are notified if acertificate stored on a hardware security module has been revoked sothat they can remove the certificate from the hardware security module.

Transaction coordinators, when acting as clients, authenticate serverswith whom they are communicating. But this check typically onlyguarantees that the server has a certificate that was issued by acertificate authority that the transaction coordinator trusts. There areno checks regarding the identity or status of the server itself. In apreferred embodiment, the transaction coordinator checks servers againsta list of trusted servers and performs OCSP checks of the server'scertificate. However, since there is little to be gained by a serverintercepting requests, the degradation of performance resulting fromthese additional checks is typically not warranted.

Typically, the transaction coordinator does not have automated processesfor detecting potential attacks. Preferably, system and securityadministrators inspect audit logs periodically in order to identify suchpotential attacks.

Typically, requests that do not pass a secure socket layer client-sideauthentication check are not logged. If an attack (e.g., a denial ofservice attack) occurs at this level, there are no logs to reference.

In a preferred embodiment, the transaction coordinator is protected by afirewall. Preferably, the firewall component maintains logs of incomingrequests.

The transaction coordinator is preferably provided with automatedintrusion detection mechanisms. These processes typically watch incomingtraffic or scan audit logs looking for suspicious activity, and takeappropriate actions if necessary.

The transaction coordinator preferably maintains logs fornon-repudiation purposes. Often, however, the system will not includefunctions to assist a user in retrieving the data necessary to supportnon-repudiation. The user manually searches through the logs to find allthe supporting data. In other embodiments, automated non-repudiationtools may be used to assist the user in this process.

In a preferred embodiment, transaction coordinators and OCSP respondersemploy normal Internet time out values for certificate status checkrequests. For other services, the time out value may be set asappropriate for the service. In a preferred embodiment, timeout valuesare configurable in the transaction coordinator.

The following discussion outlines a possible hardware and softwareimplementation for a transaction coordinator.

The main server used for the transaction coordinator may be a HewlettPackard Netserver LH4. Preferably, the server has the followingspecifications: 4 P2-450 MHZ processors, 512-768 MB RAM, 40-60 GB HDwith Raid 5 Array, UPS, and an external DLT 40E DLT 4000 tape drive fortape backup. Preferably, at least five workstations are used each havingthe following specifications: P2400 MHz processors, 128 MB RAM, and 6 GBHD.

The transaction coordinator is preferably platform independent so thatit can be supported on servers based on Microsoft Windows NT 4.0/2000,Sun Solaris, and Hewlett Packard HP-UX. Implementation is preferablydone in JAVA however some coding may be done in C/C++ as well.

A Windows NT Server w/Service Pack 3 may be used as the operatingsystem. Microsoft Visual SourceSafe 6.0 may be used for source control.Visual Café Professional Edition 3.0 from Symantec (Java Version 1.2)may be used for development. SSL/J SDK from RSA Security Systems may beused for secure socket layer implementation and is also required byXETI's JKIX.

For signature verification, nCipher's hardware security module may beused. For signatures from subscribing customers, Datakey smart cards maybe used. Preferably, OCSP responders are provided with a toolkit thatprovides an interface to cryptographic functions and for ASN.1Communication. In a preferred embodiment, XETI's JKIX may be used forthis purpose.

For digital time stamping, Datum's TYMSYNC or other trusted time sourcemay be used. An MS SQL Server may be used for the databases describedabove. Code Warner from Metro Works may be used for the development ofportable C/C++ development. CodeIntegrity may be used to perform codeintegrity checks to verify code portability.

Typically, the size of the data that is passed between differententities is instrumental in the performance of a public keyinfrastructure system. Messages submitted between entities are thereforepreferably analyzed to estimate the size of the data that istransmitted. The analysis may be done on the basis of the certificatefields defined in RFC2459 along with specific root extensions.

The exact data lengths of the certificate fields, which have a fixedlength, are preferably taken into account during the estimation.However, there are many fields for which the length varies. For thesefields, a liberal estimate on the size is preferably made (i.e., largerrather than smaller). Also, estimates of overall message size preferablyinclude the sizes for all extensions, i.e., if a message allows fivedifferent extensions, the size is preferably calculated on an assumptionthat all five extensions are being sent with the request.

FIG. 13 depicts the different message (estimated) sizes passed betweensystem entities in a preferred embodiment. As shown in FIG. 13, thetotal estimated message size of messages passed from subscribingcustomer 106 to relying customer 108 is 2610 bytes. The messagetypically comprises two certificates, each 1146 bytes, the issuingparticipant's certificate signed by root entity 110,128 bytes, theissuing participant's signature, 128 bytes, and an HTTP header, 62bytes.

The total estimated message size of messages passed from relyingcustomer 108 to relying participant 104 is 2022 bytes. The messagetypically comprises two requests, one concerning the subscribingcustomer's certificate and one concerning the issuing participant'scertificate, each 55 bytes, a message extension, 210 bytes, a versionnumber, 4 bytes, the relying participant's name, 132 bytes, the relyingparticipant's signature, 128 bytes, the relying customer's certificate,1146 bytes, and an HTTP header, 62 bytes.

The total estimated message size of messages passed from relyingparticipant 104 to issuing participant 102 is 1601 bytes. The messagetypically comprises a request concerning the subscribing customer'scertificate or the issuing participant's certificate, 55 bytes, amessage extension, 210 bytes, the root entity's signature on the relyingparticipant's transaction coordinator certificate, 128 bytes, therelying participant's transaction coordinator certificate, 1146 bytes,and an HTTP header, 62 bytes.

The total estimated message size of messages passed from issuingparticipant 102 to relying participant 104 is 2086 bytes. The messagetypically comprises a response concerning either the subscribingcustomer's certificate or the issuing participant's certificate, 456bytes, a message extension, 294 bytes, the issuing participant'scertificate, 1146 bytes, the root entity's signature, 128 bytes, and anHTTP header, 62 bytes.

The total estimated message size of messages passed from relyingparticipant 104 to relying customer 108 is 2213 bytes. The messagetypically comprises a response concerning the subscribing customer'scertificate or the issuing participant's certificate, 55 bytes, amessage extension, 210 bytes, the response from the relyingparticipant's transaction coordinator, 127 bytes, the relyingparticipant's transaction coordinator certificate, 1146 bytes, the rootentity's signature on the relying participant transaction coordinator'scertificate, 128 bytes, and an HTTP header 62 bytes.

The detail on message size estimation of different fields is depicted inthe table below. Typically, the size of message being passed between theentities is between 2K and 3K. Once the transaction volume has beenprojected, this information is preferably used to estimate the networkload.

Certificate Size - No Extensions or Root Specific instructions SizeCertificate{ (in Bytes) Size Calculation Comments  TbsCertificate {    Version  Integer 4     Serial Number 4     Integer     signature {   Algorithm  Object 11       Identifier    Parameters  Defined by 32Signature algorithm parameters are usually       Algorithm NULL butsince parameters are allowed, 32 bytes have been assigned for it   }  issuer Name 132 This is a higher estimate - approximated for 4 names.Name is defined as sequence of Relative Distinguished Name   validity {   notBefore {     utcTime UTCTime 32     generalTime 32  GeneralizedTime   }    notAfter {     utcTime UTCTime 32     generalTime 32 Generalized Time    }   }  subject Name 132 This is a higher estimate -approximated for 4 names. Name is defined sequence of RelativeDistinguished Names  subjectPublicKeylnfo {   algorithm {    AlgorithmObject 11 Identifier    Parameters Defined by 32 Signature algorithmparameters are usually algorithm NULL but since parameters are allowed,32 bytes have been assigned for it   }   subjectPublicKey BIT STRING 128 }   issuerUniqueID BIT STRING 132 This is higher estimate. Usually ifIssuer is defined, issuerUniquelD should not be used   subjectUniqueIDBIT STRING 132 This is higher estimate. Usually if Subject is defined,subjectUniquelD should not be used    extensions {    extnID Object 0Certificate is being estimated without any Identifier extensions. extnlDwould take 11 bytes.     critical BOOLEAN 0 BOOLEAN would take 4 bytes    extnValue OCTET 0 Will depend upon the extension STRING   }  } Signature Algorithm {   algorithm Object Identifier 11   parametersDefined by 32 Algorithm  }  Signature Value BIT STRING 128 This may varyfrom signer to signer. When signed by root, the size will be 256 whensigned by the root } Total 985

Certificate Extension - with Root Instructions and Extensions SizeCertificate Extension root entity (in Specific Instruction Bytes) SizeCalculation Comment Must not contain Issuer Unique ID −132 Must notcontain Subject Unique ID −132 Contain a Subject DN 0 Already present incertificate Extension subjectAltNames is supported 47 Consists f anumber of GeneralNames - as e-mail root entity will support onlyrfc822 - email address - estimated at 32 bytes + 11 bytes for extnlD and4 bytes for critical flag Extension KeyUsage should appear in all 17 2bytes for the bit string + 15 for extension Certificates parametersExtended Key usage should appear when 65 Consists of OID. Estimated at 5OID = 55 appropriate Bytes + 15 for extension parameters CertificatePolicies should be present with 26 11 bytes for root entity OID + 15 forOID extension parameters Basic Constraints should be present 19 4 bytesfor the Boolean + 0 bytes for the path since path is not being used + 15bytes for extension parameters Subject Key ID should be present 35 20bytes based on 160-bit SHA-1 hash + 15 bytes for extension parametersAuthority Key ID should be present 103 20 bytes for the hash + 64 forthe General Name - assumption that it could be URI + 52 + 4 for serial +15 for extension parameters Must not contain Name Constraint 0 0 Mustnot contain Policy Constraint 0 0 ALA must be used for OCSP and RM 90 64bytes for general name + 11 bytes for OID + 15 for extension parametersExtension - Subscriber Information 55 20 bytes for warranty account + 20bytes for device id + 15 bytes for extension parameters Total 193

OCSP Request - with Root Instructions & Extensions Size (in  OCSPRequest Bytes) Size Calculation Comments  TbsRequest {  Version  Integer 4   RequestorName Name 132   Request { The Requeststructure repeats for each request in a particular OCSP request.   ReqCert {     CertID {       HastAlgorithm {       Algorithm OID 11      Parameters 0 Estimated as O since no          Defined byparameters passed          Algorithm on the implementation.    }   }  IssuerNameHash 20   IssuerKeyHash 20   SerialNumber 4 } } }  } Total(Without Extensions) 191 RequestExtensions {   Nonce {   OID 11   NonceValue 24 No requirements have been imposed on Nonce Value. Estimated at24 bytes  }  ServiceLocator {   IssuerName 132   ALA 32   OID 11 }  }Total (With Extensions) 401

OCSP Response - with Root Instructions & Extensions Size SizeCalculation OCSP Response (in Bytes) Comments  ResponseStatus {  ResponseBytes {    ResponseType OID 11    Response 32   }  BasicOCSPResponse {    TbsResponseData {     Version Integer 4    ResponderID Name 132     ProucedAT GeneralizedTime 32    }   Responses { Repeated for each response     CertID {      Algorithm {      algorithm OID 22       parameters Defined by 0       Algorithm    }     issuerNameHash 20     issuerKeyHash 20       serialNumber 4    }     CertStatus 8     ThisUpdate 32     NextUpdate 0 Not to be usedin root entity Responses  }    SignatureAlgorithm {     Algorithm {      algorithm 11       Parameters 0     }    } 0    SignatureValue 128} Total (Without Extensions) 456 ResponseExtensions {    Nonce {     OID11     Nonce Value 24    }    CRLEntryExtension {     Reason OID 11    ReasonCd Enum 4    HoldlnstructionCd OID 11    Holdlnstniction OID11    Invalidity Date GeneralizedTime 32    Certificatelssuer OID 11   CertificatelssuerName Name 132   }   CRLReason {    Reason OID 11   ReasonedCd Enum 4    Time GeneralizedTime 32 } Total (WithExtensions) 750

Valid request and response times for OCSP transactions and warrantytransactions and confirmation times for all transactions are preferablyspecified by root entity 110. The following section describes preferredperformance targets for the transaction coordinator. The response timesnoted refer specifically to the system response time. Preferably, lapsedtimeframes in which manual processes are completed (noting the need forverification and requesting it, filing claims, etc.) are alsoestablished.

Preferably, the validation request and response time (i.e., OCSP) is tenseconds or less for all response time transactions within the rootcontrol infrastructure. Validation outside the root infrastructure (fromcustomer to customer or customer to root) preferably does not exceedsixty seconds. The total round-trip time preferably does not exceedseventy seconds. Preferably the response time includes latency on theInternet. The end-to-end response time preferably includes the longestvalidation path (i.e. subscribing customer to relying customer torelying participant to issuing participant to root entity).

An illustrative performance requirement may be as follows: No more than6 seconds between the post of a certificate status check to a relyingparticipant's transaction coordinator and receipt of a response and nomore than 3 seconds to turn around a response to a certificate statuscheck where the data for the response is locally available in a casewhere caching is in effect, proof of freshness (i.e., including statusof participant certificates in messages transmitted by the participant)is in effect, a certificate chain of two certificates is beingvalidated, the transaction is a four-corner transaction, and the systementities are connected to a 10 Mbps LAN (rather than the Internet).

The warranty request response time includes offline transactions.Preferably, these offline transactions do not exceed an eight hourwindow starting at the end of a business day.

The response time for response to notification of lost, compromised, orinvalid certificates preferably includes offline transactions.Preferably, these offline transaction do not exceed one hour.

The revocation of certificates also preferably includes offlinetransactions. Preferably, these offline transactions do not exceed onehour.

The transaction coordinator also preferably provides confirmation oftransactions. Online transaction requests preferably receive statusconfirmation, including incomplete request or response, within seventyseconds. The transaction coordinator also preferably provides a methodof storing for retrieval incomplete transaction requests or responses, areceipt of request status, an incomplete request response, andtransaction queuing for incomplete transaction.

The transaction coordinator also preferably comprises transactionrecovery requirements. Appropriate system resource allocation preferablyallows for transaction roll-back.

The transaction coordinator also preferably provides system fail-overrequirements. In a preferred embodiment, the transaction coordinator isprovided with system redundancy, system/hot back-up, and redundancywithin the public Internet.

During the development of the transaction coordinator, a performancebaseline in the development environment is preferably established. Thisbase-line information is used to improve the performance of theapplication components on the development machine itself. However, toachieve a preferred target performance, appropriate production hardwarecapable of supporting the anticipated number of transactions and anetwork with appropriate band-width are typically put in place.

The following sections discuss preferred tuning strategies for higherperformance of the transaction coordinator.

It may be possible to reduce the size of messages being passed betweenentities by eliminating some or all of the certificates sent with eachmessage. Typically the recipient of a message knows the identity of thesender (i.e., his distinguished name as it appears in his warrantycertificate) and has access to his full certification path. Many of theneeded certificates are also available from local repositories.

OCSP checks performed as part of the authentication process may beeliminated if the customer database is designed to reflect revokedcertificates and if authorization checks are performed against a user'sdistinguished name and certificate, as opposed to just its distinguishedname.

In a preferred embodiment described above, the transaction coordinatorstores raw transaction data and then parses the data to separately storea subset of the data for billing purposes. Alternatively, however, thisfunction may be offloaded to an off-line process that monitors the rawtransaction database and extracts relevant billing data from the datastored in the database.

Co-locating the transaction coordinator and OCSP responder eliminatesthe need to sign and verify requests and to establish secure socketlayer connections between these components.

Using secure socket layer between financial institutions and duringcommunications with root entity 110 typically eliminates the need todigitally sign each request message. However, digitally signed requestsprovide a higher degree of security. Each participant may preferablyassess the risks involved with trading off security for performance.

Caching OCSP responses typically improves the turnaround time byreducing the time it takes to send and receive an OCSP request to theroot entity. In a preferred embodiment, verification of OCSP responsesis performed as the data is put into the cache as opposed to performingverification as part of the on-line transaction processing.

In a preferred embodiment, a transaction coordinator may cache validityresponses and use the cached responses to validate credentials. Theperiod for which a response may be cached is preferably set as a policymatter by root entity 110. This period may preferably be within the 4 to5 minute range.

If a transaction coordinator implements the ability to used cachedresponses it is preferably adapted to log their use for billing andaudit as well as non-repudiation purposes. The logged informationpreferably indicates that a cached response was used to validate acredential rather than a freshly acquired response.

For high value transactions, a client application may prefer the use ofa fresh response rather than a cached response. Accordingly, in apreferred embodiment, transaction coordinators preferably get and use afreshly acquired validity response on explicit request to use a freshresponse rather than a cached response.

In a preferred embodiment, the recipient of a response checks the statusof the responder's certificate. Alternatively, to eliminate this secondrequest, the transaction coordinator may automatically include thestatus of its certificate (as signed by the root) whenever it sends aresponse to either a relying customer or to another transactioncoordinator.

The following section discusses testing of the transaction coordinator.Preferably, the transaction coordinator is tested for the items listedin this section.

In order to provide architectural flexibility, the transactioncoordinator is preferably ported to more than one hardware platform(e.g. Microsoft Windows NT 4.0/2000, Sun Solaris and Hewlett PackardHP-UX). This allows participants to choose their own hardware platformfrom the list of the supported platforms. Tests are preferably performedto ensure that the transaction coordinator is installed smoothly on eachof the supported platforms. To enable such testing appropriate hardwareis typically required.

Tests are preferably performed to ensure that the transactioncoordinator may be installed and uninstalled on a clean Windows NTMachine.

If the transaction coordinator is extended to support other operatingsystems, tests are preferably performed to ensure that the executablederived from the same source code can be installed on all of thesupported operating systems. Appropriate hardware with appropriateoperating systems may be required to perform these tests.

Preferably, the transaction coordinator interfaces with other thirdparty vendors' software tools. The interfaces to these software toolsare preferably tested on the development site during development andsystem test phase. In addition, elaborate testing is typically done atthe customer site to ensure that the transaction coordinator interfacewith these tools is stable. This may be done duringcustomer/functionality testing, described below.

The functionality of the transaction coordinator is preferably testedduring development and system test phases. During these tests,appropriate tools are used to ensure that all of the custom written codeis exercised at least once. In a another preferred testing phase,customers test the functionality of the transaction coordinator.

Security is a critical piece of the transaction coordinator. Preferably,testing is done to ensure that data is transferred securely from onepoint to another. Test cases are preferably created to exhaustively testthe security aspect of the public key infrastructure.

A messaging protocol definition for messages transmitted within system200 and a certificate status protocol definition for system 200 aredescribed in copending U.S. provisional patent application Ser. No.60/231,319, filed Sep. 8, 2000, entitled Transaction CoordinatorCertificate Status Check (CSC) Protocol Definition, TransactionCoordinator Messaging Protocol Definition, and Transaction CoordinatorRequirements, which is hereby incorporated by reference. In a preferredembodiment, each transaction coordinator supports this messagingprotocol definition. Specifically, each transaction coordinator acceptsand routes all valid XML messages as defined in the messaging protocoldefinition, logs and reports ill-formed messages, and is able togenerate valid XML messages in response to requests.

In an alternative embodiment, the system may instead be implemented asan OCSP centric model that does not employ transaction coordinators 202.This alternative embodiment employs enhanced OCSP responders adapted toprovide significantly more functionality than normally provided by atypical OCSP responder. In particular, the enhanced OCSP responder isadapted to provide the following additional functionality:

-   -   Encrypted communication using SSL.    -   Logging of raw transactions for both requests and responses.    -   Providing of certificate chains with responses.    -   Verification of signatures on requests preferably using an HSM.    -   Validation of certificate chains accompanying requests (parts of        which may be stored in a local database or on an HSM).    -   Creation of new requests based on:        -   A value in a service locator request extension of a received            request.        -   An authority information-access extension in the certificate            accompanying a response.    -   Suspension of processing on a request until responses are        received on these other newly created requests, i.e., ability to        synchronize responses to requests.    -   Forwarding of responses, when appropriate.

This alternative embodiment provides only portions of the certificatestatus check service without providing the flexibility of adding newservices. Also, billing is not implemented in this alternativeembodiment. In addition, this alternative embodiment may cause vendorlocking A detailed list of the pros and cons of this alternativeembodiment is provided below.

FIG. 14 depicts the transaction flows for this alternative embodiment.The message flows in FIG. 14 are summarized in the following table:

1 The Subscribing Customer (SC) sends signed data, the signature, the SCand the IP certificates (and optionally CSSD) to the Relying Customer(RC). 2 The RC verifies the signature on the data sent by the SC andvalidates the SC's certificate chain and then creates an OCSP requestcontaining the SC certificate serial number. This data is sent to theHSM for signature. 3 The OCSP request for the SC's certificate, signedby the RC is sent to the Relying Participant (RP) OCSP Responder (OR)along with the RC's certificate chain. The entire certificate chain mustbe passed with the message. 4 The RP OCSP Responder logs the request inits OCSP log. The RP OCSP Responder verifies the signature on therequest and validates the RC's certificate chain. All verification ifperformed is software. The entire chain (including the root) must bepassed with the message in order for verification of thesignature/certificate chain to be performed. No checks are performed toensure that the RC's certificate has not been revoked. 5 The RP OCSPResponder creates a new request, containing the single request receivedfrom the RC, and signs it using its HSM. Signed requests betweenfinancial institutions are not required. Instead, the root entity (ROOT)may require SSL client- side authentication in which case theverification/validation/customer look up is based on the certificatesassociated with the SSL connection. 6 The RP OCSP Responder sends thesigned OCSP request to the appropriate Issuing Participant's OCSPResponder based on the value in the Service Locator request extension ofthe received request. 7 The IP OCSP Responder logs the request in itsOCSP log. The IP OCSP Responder verifies the signature on the requestand validates the RP OR's certificate chain. All verification ifperformed in software. The entire chain (including the root) must bepassed with the message in order for verification of thesignature/certificate chain to be performed. 8 The IP OCSP Respondercreates an OCSP request containing the serial number of the RP OCSPResponder's certificate and signs it using its HSM. 9 The IP OCSPResponder then sends the request to the ROOT OCSP Responder based on theauthority information access extension in the certificate associatedwith the signature on the request received in Step 4. The IP OCSPResponder waits for a response from the ROOT regarding the RP OCSPResponder's certificate before issuing a response on the SC'scertificate. If the IP only requires SSL client-side authentication anddoes not require signed OCSP requests, this step may not be necessary.10 The ROOT OCSP Responder logs the request in its OCSP log. The ROOTOCSP Responder verifies the signature on the request and validates theIP OCSP Responder's certificate chain. Signed requests between financialinstitutions are not required. Instead, the ROOT may require SSLclient-side authentication in which case theverification/validation/customer look up is based on the certificatesassociated with the SSL connection. 11 The ROOT OCSP Responder checksits local database to determine the status of the RP OCSP Responder'scertificate, then it generates a response and signs it using its HSM. 12The ROOT OCSP Responder then returns the response to the IP OCSPResponder. 13 The IP OCSP Responder logs the response in its OCSP log.The IP OCSP Responder verifies the signature on the request andvalidates the Root's OCSP Responder certificate chain. It should benoted, however, that there may not be enough information maintained inthe logs to support non-repudiation. The entire certificate chain mustbe passed with the message. 14 The DP OCSP Responder then checks itslocal database to determine the status of the SC's certificate. The IPOCSP Responder generates a response and signs it using its HSM. 15 TheIP OCSP Responder sends the signed response to the RP OCSP Responder. 16The RP OCSP Responder logs the OCSP response in the OCSP log. The RPOCSP Responder verifies the signature on the response and validates theIP's OCSP Responder certificate chain. The entire certificate chain mustbe passed with the message. 17 The RP OCSP Responder creates an OCSPrequest containing the serial number of the IP OCSP Responder'scertificate and signs it using its HSM. 18 The RP OCSP Responder thensends the request to the ROOT OCSP Responder based on the authorityinformation access extension in the certificate associated with thesignature on the response received in step 14. 19 The ROOT OCSPResponder logs the raw request in its OCSP log. The ROOT OCSP Responderverifies the signature on the request and validates the entire RP OCSPResponder's certificate chain. The entire certificate chain must bepassed with the message. 20 The ROOT OCSP Responder checks its localdatabase to determine the status of the IP OCSP Responder's certificate,then it generates a response and signs it using its HSM. 21 The ROOTOCSP Responder sends the signed response to the OCSP Responder. 22 TheRP OCSP Responder logs the response in its OCSP log. The RP OCSPResponder verifies the signature on the response and validates theRoot's OCSP Responder certificate chain. The certificate chain may bepassed with the message, or parts of the chain may reside either on theHSM or in the Certificate Verification database. 23 The RP OCSPResponder creates a response for the RC that contains information itreceived in step 2 (e.g., the nonce) and the status information on theSC's certificate it received in step 14 and signs it using its HSM. 24The RP OCSP Responder returns the response to the RC. 25 The RC uses itsHSM to verify the signature on the response and validate the RP's OCSPResponder certificate chain. The certificate chain may be passed withthe message, or parts of the chain may reside on the HSM. 26 The RCcreates an OCSP request containing the IP's certificate serial number.This data is sent to the HSM for signature. 27 The OCSP request for theIP's certificate, signed by the RC, is sent to the Relying Participant(RP) OCSP Responder (OR) along with the RC's certificate chain. Theentire certificate chain needs to be passed with the message. 28 The RPOCSP Responder logs the request in its OCSP log. The RP OCSP Responderverifies the signature on the request and validates the RC's certificatechain. All verification if performed in software. The entire chain(including the root) must be passed with the message in order forverification of the signature/certificate chain to be performed. Nochecks are performed to ensure that the RC's certificate has not beenrevoked. 29 The RP OCSP Responder creates a new request, containing thesingle request received from the RC, and signs it using its HSM. Signedrequests between financial institutions are not required. Instead, theROOT may require SSL client-side authentication in which case theverification/validation/customer look up is based on the certificatesassociated with the SSL connection. 30 The RP OCSP Responder sends thesigned OCSP request to the ROOT OCSP Responder based on the value in theService Locator request extension of the received request. 31 The ROOTOCSP Responder logs the request in its OCSP log. The ROOT OCSP Responderverifies the signature on the request and validates the RP OR'scertificate chain. All verification is performed in software. The entirechain (including the root) must be passed with the message in order forverification of the signature/certificate chain to be performed. 32 TheROOT OCSP Responder checks its local database to determine the status ofthe RP OCSP Responder's certificate, then it generates a response andsigns it using its HSM. 33 The ROOT OCSP Responder then returns theresponse to the RP OCSP Responder. 34 The RP OCSP Responder logs theresponse in its OCSP log. The RP OCSP Responder verifies the signatureon the response and validates the ROOT's OCSP Responder certificatechain. It should be noted that there may not be enough informationmaintained in the logs to support non-repudiation. The entirecertificate chain must be passed with the message.

This OCSP proxy centric model has advantages and disadvantages whencompared to the transaction coordinator model described above. The prosand cons of this alternative embodiment are summarized in the tablebelow:

Pros Cons Takes away some of Two OCSP Responder are required: one thecomplexity of that re-signs responses, one that forwards implementingthe signed responses without re-signing. transaction coordinator as aninitial phase by reducing functionality and pushing code changes to themanufacturer of the OCSP responder. Allows the basic security Noauthorization checks are performed. infrastructure to be Signatures areverified by the OCSP put in place and tested. Responder but there are nochecks performed to determine whether or not the request is from anauthorized customer. There are no OCSP checks performed to determine ifa requestor's certificate has been revoked. All certificates in arequestor's/responder's chain must be sent with the request/ response inorder for the OCSP Responder to verify the signatures. Thissignificantly increases the size of the messages. The RC must sendindividual requests to the RP—multiple certificate statuses cannot berequested in the same message if they need to be processed by differentOCSP responders. Not enough information is maintained in the logs fornon-repudiation purposes. It is not clear whether enough informationabout the requestor is retained for billing purposes. Can only performcertification status checks. Will still require a transactioncoordinator to fulfill other services. Will not provide generic reusablecore components. The IETF OCSP Responder specification does not requireResponder to provide this additional functionality.

Technical and security requirements for OCSP responder 204 arepreferably specified by root entity 110. An exemplary set ofrequirements is described below.

Technical Requirements

In a preferred embodiment, each OCSP responder 204 operates pursuant tothe Online Certificate Status Protocol (OCSP).

In a preferred embodiment, when an OCSP responder 204 receives an OCSPrequest, it validates the requestor's certificate, authenticates therequestor, and verifies that the requestor is a contracted system userwith the participant that received the request by performing a localstatus check on the requestor's certificate. Authentication of therequestor may be accomplished using the signed OCSP request, in the caseof an inter-institution request, or through secure socket layers clientauthentication, in the case of a customer request. In addition, securesocket layers may be required to ensure the confidentiality of allrequests.

In a preferred embodiment, each OCSP responder 204 selects peer serverswhen making inter-institution requests based on a locator extension ofthe requested service and a local table. In an alternative embodiment,this information may be obtained by lightweight directory accessprotocol (LDAP) look up.

In a preferred embodiment, each OCSP responder 204 may cachecertificates subject to rules specified by root entity 110.

In a preferred embodiment, each OCSP responder 204 verifies thatinter-institution responses have been signed by an authorized respondercertificate. For inter-institution OCSP requests, the OCSP responder ofthe relying participant 204 preferably re-signs the response from, e.g.,issuing participant 102 before transmitting it to the requestor.

In a preferred embodiment, each OCSP responder supports the followingresponses: “revoked,” “good,” and “unknown.” If a client OCSP responderreceives a “revoked” response regarding a particular certificateproduced at a time t, then the client OCSP responder assumes that thatcertificate, or some certificate in the certificate chain of thatcertificate was revoked prior to time t. As such, the client OCSPresponder does not possess sufficient evidence to transfer liability fordocuments that have been digitally signed after time t using the privatekey corresponding to the checked certificate to the server OCSPresponder.

If a client OCSP responder receives a “good” response regarding aparticular certificate, produced at a time t, then the client OCSPresponder assumes that that certificate and every other certificate inits certificate chain was in good standing at time t. As such, theclient OCSP responder has sufficient evidence to transfer liability fordocuments that have been digitally signed prior to time t to the serverOCSP responder.

If the client OCSP responder receives an “unknown” response regarding aparticular certificate produced at time t, then the client OCSPresponder assumes that that certificate, or a certificate in thecertificate chain of that certificate, is not known to be in goodstanding. As such, the client OCSP responder does not possess sufficientevidence to transfer liability for documents that have been digitallysigned using the private key corresponding to the checked certificate tothe server OCSP responder.

Security Requirements

In a preferred embodiment, each OCSP responder 204 stores its privatekeys in a hardware security module that meets requirements establishedby root entity 110.

In a preferred embodiment, each OCSP. responder 204 uses separate keysfor server secure socket layers, client secure socket layers, and OCSPresponses.

In a preferred embodiment, each OCSP responder 204 has the ability tooperate on institution-hardened platform configurations. Aninstitution-hardened platform is a tried and tested platform that isapproved for use within an institution's firewall.

In a preferred embodiment, each OCSP responder 204 maintains detailedlogs of all signed requests and responses, all exceptions or errors, andall administrative and configuration actions.

In a preferred embodiment, each OCSP responder 204 uses strongauthentication, such as secure socket layers client authentication, toauthenticate entities for all administrative transactions.

In a preferred embodiment, each OCSP responder 204 meets minimumsecurity requirements established by root entity 110. In addition, theinstitution that maintains the OCSP responder may specify additionalOCSP responder security rules.

In a preferred embodiment, each OCSP responder 204 is configured to behighly available and deployable in a replicated mode. In addition, eachOCSP Responder preferably responds to all requests in less than onesecond.

OCSP responders are not typically required to perform checks on utilitycertificates. They may, however, be configured to allow a requestorunauthenticated access to the status of a utility certificate.

In a preferred embodiment, an OCSP responder may be required to serve asan authenticated interface to an institution's repository.Implementation details of this preferred embodiment may be left to theentity that maintains the OCSP responder.

In a preferred embodiment, each OCSP Responder comprises additionalinterfaces to support additional functionality. In particular, each OCSPresponder preferably comprises an additional interface to makeinformation available to support a participant's customer-servicerequirements. In addition, each OCSP responder preferably comprises aninstitution-defined standard interface for exporting system and eventlogs. Each OCSP responder may also comprise an interface for export ofinformation for billing applications. Billing data may be exported inany format including logs but preferably enables the requestor todetermine the type and volume of the request.

In a preferred embodiment, participants 102, 104 shown in FIG. 1 arereferred to as level-one participants because they are issued digitalcertificates directly by root entity 110. Accordingly, the certificatechain of each participant begins at root entity 110. Each level oneparticipant relies on root entity 110 to obtain the status ofcertificates of other level-one participants.

In a further preferred embodiment, the present system may compriseadditional participants, called level-two participants. Each level-twoparticipant is preferably issued a digital certificate by a level-oneparticipant with which it is associated. These level-two participantsmay then serve as certificate authorities for their respective customersand provide system services to those customers.

Level one participants preferably provide the highest point of trust forlevel two participants. As such, level two participants preferablyreport directly to their sponsoring level one participant. Level twoparticipants must also rely on their sponsoring level one participantsto obtain the status of certificates of other participants. A preferredembodiment including level one and level two participants is furtherdescribed in copending U.S. patent application Ser. No. 09/502,450,filed Feb. 11, 2000, entitled System and Method for ProvidingCertification-Related and other Services, which is hereby incorporatedby reference.

In a preferred embodiment, each participant collectively implements andmaintains a hardware and software configuration baseline that identifiesthe operating environment of the hardware and software components ofeach participant. As such, the configuration baseline serves as aconfiguration reference which facilitates the daily operation andmanagement of the system. The baseline facilitates the integration ofconfiguration changes made by one or more participants on a system-widelevel. In addition, the baseline facilitates system-wide servicerecovery in the event of hardware or software failures of one or morecertification authorities.

In a preferred embodiment, a master copy of the configuration baselinefor the present system is maintained by root entity 110. Typically, themaster copy is kept by an officer of root entity 110, such as the VicePresident of Operations.

In a preferred embodiment, root entity 110 keeps a true and accuraterecord of root entity 110's hardware and software configuration. Atleast three copies of the root certification authority's configurationbaseline are preferably retained by root entity 110 at the followingthree locations: (1) at the same physical location of the rootcertification authority thereby allowing operational changes to berecorded as they occur; (2) at a secure location outside the physicallocation of the root certification authority but in a controlledcontainer; and (3) at an offsite location with root entity 110's backupand archive records. Other copies of this hardware and softwareconfiguration may be provided to level one certification authorities atthe discretion of root entity 110.

In a preferred embodiment, each level one participant maintains a trueand accurate record of the hardware and software configuration of itscertification authority architecture. Each level one participantpreferably prepares, retains, and maintains at least three copies of itsconfiguration baseline document in the following three locations: (1) atthe same physical location of the level one certification authoritythereby allowing operational changes to be recorded as they occur; (2)at a secure location outside the physical location of the level onecertification authority but in a controlled container; and (3) at anoffsite location with the level one certification authority's backup andarchive records. In addition, each level one participant preferablyprovides a copy of its configuration baseline to root entity 110.

In a preferred embodiment, level two participants also maintain a trueand accurate record of the hardware and software configuration of theircertification authority architecture. Each level two participantprepares, retains, and maintains at least three copies of itsconfiguration document in the following three locations: (1) at the samephysical location as the level two certification authority therebyallowing operational changes to be recorded as they occur; (2) at asecure location outside the physical location of the level twocertification authority but in a controlled container; and (3) at anoff-site location with the level two certification authority's back upand archive records. In addition, each level two participant preferablyprovides a copy of its configuration baseline to its sponsoring levelone certification authority.

Forms may be provided to facilitate documentation of hardware andsoftware configurations. In a preferred embodiment, the hardware andsoftware configurations of root entity 110's and each participant'scertification authority directory, OC SP responder, and Internetfirewall are also documented.

In a preferred embodiment, root entity 110 has primary responsibilityfor configuration management on a system-wide level. This responsibilityis typically delegated to an officer of root entity 110, such as theVice President of Operations. Each certificate authority preferablycomprises a technical operations staff which has the operationalresponsibility for maintaining an accurate record of the certificationauthority's hardware and software configuration.

In a preferred embodiment, the initial configuration baseline of eachcertificate authority is produced by commissioning the configurationbaselines of each subordinate certification authority.

In a preferred embodiment, a configuration change must comply with thefollowing criteria: (1) a configuration change must be required toaddress a defined system requirement; (2) a configuration change must berecommended by the certification authority's operations staff; (3) aconfiguration change to the operational platforms must be approved by anofficer, such as the Vice President of Operations in the case of theroot entity, and a senior manager accountable for the integrity of thecertification authority, in the case of a level one or level twocertification authority; (4) notice of configuration changes must begiven to any affected parties; (5) a configuration change must take intoaccount relevant configuration change criteria imposed by governmentalor standards setting bodies; and (6) a configuration change must berecorded by setting out the date of the change and the period of eachprevious configuration. Each certificate authority typically archivesconfiguration changes with other archived materials such as backuptapes.

In a preferred embodiment, the configuration baseline is implemented inconjunction with the root entity's system security policy and is anaudited component of each certification authority.

While the invention has been described in conjunction with specificembodiments, it is evident that numerous alternatives, modifications,and variations will be apparent to those skilled in the art in light ofthe foregoing description.

What is claimed is:
 1. A system for providing a digital certificatestatus check service via a computer network, the system comprising: aroot entity server comprising a first transaction coordinator; at leastone issuing participant server comprising a second transactioncoordinator; and at least one relying participant server comprising athird transaction coordinator; wherein each respective transactioncoordinator comprises a digital certificate authentication andvalidation module that determines a status of digital certificates,receives online digital certificate status requests from the transactioncoordinator, and transmits the online digital certificate statusresponses to the transaction coordinator; and wherein coupled to eachdigital certificate authentication and validation module is a hardwaresecurity module.
 2. The system of claim 1, wherein each respectivedigital certificate authentication and validation module transmits arevoked status associated with a checked digital certificate in responseto the module determining the checked digital certificate, or a linkedcertificate in a certificate chain with the checked digital certificate,has been revoked prior to a particular time.
 3. The system of claim 2,wherein the at least one issuing participant server transmits adisclaimer of liability for documents that have been digitally signed bythe check digital certificate in the certificate chain after theparticular time.
 4. The system of claim 1, wherein each respectivedigital certificate authentication and validation module transmits avalid status associated with a checked digital certificate in responseto the module determining the checked digital certificate, and everyother certificate in a certificate chain with the checked digitalcertificate, is in good standing as of a particular time.
 5. The systemof claim 4, wherein the at least one issuing participant transmits anacceptance of liability for documents that have been digitally signed bythe checked digital certificate in the certificate chain prior to theparticular time using a private key corresponding to the checked digitalcertificate.
 6. The system of claim 1, wherein each digital certificateauthentication and validation module transmits an unknown statusassociated with a checked digital certificate in response to the moduledetermining the checked digital certificate, or a certificate in acertificate chain with the checked digital certificate, is not known tobe in good standing.
 7. The system of claim 6, wherein the at least oneissuing participant server transmits a disclaimer of liability fordocuments that have been digitally signed using a private keycorresponding to the checked digital certificate.
 8. The system of claim1, wherein each respective digital certificate authentication andvalidation module stores private keys in non-transitory memory of thecoupled hardware security module.
 9. The system of claim 1, wherein eachdigital certificate authentication and validation module meets a set ofminimum security requirements established by the root entity.
 10. Thesystem of claim 1, wherein at least one digital certificateauthentication and validation module is an online certificate statusprotocol responder.
 11. The system of claim 1, wherein at least onedigital certificate authentication and validation module uses eXtensibleMarkup Language.
 12. A computer-implemented method for providing adigital certificate status check service via a computer network, saidmethod comprising: providing a root entity server, at least one issuingparticipant server, and at least one relying participant server; andproviding each of the root entity server, each issuing participantserver, and each relying participant server with a microprocessor-basedtransaction coordinator; coupling to each respective transactioncoordinator a digital certificate authentication and validation moduleexecuting a set of instruction to check a status of digitalcertificates, to receive online certificate status requests from thetransaction coordinator, and to transmit online certificate statusresponses to the transaction coordinator; and coupling to eachrespective digital certificate authentication and validation module ahardware security module.
 13. The method of claim 12, wherein a digitalcertificate authentication and validation module transmits a revokedresponse regarding a checked digital certificate when the checkeddigital certificate, or a certificate in a certificate chain with thechecked digital certificate, has been revoked prior to a particulartime.
 14. The method of claim 13, wherein each issuing participantserver disclaims liability for documents that have been digitally signedafter the particular time.
 15. The method of claim 12, wherein a digitalcertificate authentication and validation module transmits a goodresponse regarding a checked digital certificate when the checkeddigital certificate, and every other certificate in a certificate chainwith the checked digital certificate, is in good standing as of aparticular time.
 16. The method of claim 15, wherein each issuingparticipant server accepts liability for documents that have beendigitally signed prior to the particular time using a private keycorresponding to the checked digital certificate.
 17. The method ofclaim 12, wherein a digital certificate authentication and validationmodule transmits an “unknown” response regarding a checked digitalcertificate when the checked digital certificate, or a certificate in acertificate chain with the checked digital certificate, is not known tobe in good standing.
 18. The method of claim 17, wherein each issuingparticipant server disclaims liability for documents that have beendigitally signed using a private key corresponding to the checkeddigital certificate.
 19. The method of claim 12, wherein each respectivedigital certificate authentication and validation module stores one ormore private keys in non-transitory machine-readable memory of thehardware security module.
 20. The method of claim 12, wherein eachdigital certificate authentication and validation module meets a set ofminimum security requirements established by the root entity server. 21.The method of claim 12, wherein at least one digital certificateauthentication and validation module is an online certificate statusprotocol responder.
 22. The method of claim 12, wherein at least onedigital certificate authentication and validation module uses eXtensibleMarkup Language.
 23. A computer-implemented method comprising:receiving, by a first processor of a first transaction coordinatorassociated with an issuing participant server, from a second processorof a second transaction coordinator a request for a status of a digitalcertificate associated with a first certificate authority; querying, bythe first processor, the first certificate authority based on therequest, wherein the first certificate authority stores the status ofone or more digital certificates in non-transitory machine-readablememory; determining, by the first processor, the status of the digitalcertificate responsive to querying the first certificate authority; andupon determining the status of the digital certificate: transmitting, bythe first processor, to the second processor a response comprising thestatus of the digital certificate and an indicator of liability.
 24. Themethod according to claim 23, wherein determining the status of thedigital certificate further comprises: querying, by the first processor,a next-higher certificate authority storing the status of one or moredigital certificates in non-transitory machine-readable memory, whereinthe next-higher certificate authority comparatively above the firstcertificate authority in a hierarchy of one or more certificateauthorities.
 25. The method according to claim 24, wherein the issuingparticipant server comprises the first certificate authority.
 26. Themethod according to claim 25, wherein the second transaction coordinatoris associated with a relying participant server.
 27. The methodaccording to claim 26, wherein a root certificate authority is acomparatively highest certificate authority in relation to the firstcertificate authority, wherein the root certificate authority is acomparatively highest certificate authority in relation to a secondcertificate authority, and wherein the second certificate authority isassociated with the relying participant server.
 28. The method accordingto claim 23, wherein determining the status of the digital certificatefurther comprises: identifying, by the first processor, the status of anext-higher digital certificate in a certificate chain containing thedigital certificate.
 29. The method according to claim 23, whereindetermining the status of the digital certificate further comprises:identifying, by the first processor, a revoked status for the digitalcertificate prior to a particular time, wherein the status of thedigital certificate is invalid.
 30. The method according to claim 29,wherein the indicator of liability contains a disclaimer of liabilityassociated with a machine-readable document digitally signed with thedigital certificate after the particular time.
 31. The method accordingto claim 23, wherein determining the status of the digital certificatefurther comprises: identifying, by the first processor, a valid statusfor the digital certificate after a particular time, wherein the statusof the digital certificate is valid.
 32. The method according to claim31, wherein the indicator of liability contains an acceptance ofliability associated with a machine-readable document digitally signedwith the digital certificate before the particular time.
 33. The methodaccording to claim 23, wherein determining the status of the digitalcertificate further comprises: identifying, by the first processor, anunknown status for the digital certificate, wherein the status of thedigital certificate is unknown.